tl;dr: I disagree. What do you suggest?

First off. Everything being said in this issue, including my opinions, are opinions and not fact. Someone says something is an implantation detail. I say it's not. Ok, great? We are trying to represent HTTP messages in PHP based on a standard that makes no dictation about how it should be utilized in PHP. That means we are going to have to make some opinionated decisions on what is the final product.  That means that everything being discussed is someone's interpretation on how this should be implemented.

Creating a standard that cant handle large payloads out of the gate does nothing to help the community and makes the standard irrelevant from the start. You mentioned that every language standard of consequence uses native types. Define "of consequence". Python actually has an object oriented IO object (that my suggested interface is based on). Java's HttpComponents have a very similar interface for their message bodies.

PHP streams are not a good alternative. Implementations that represent their payloads as something like the StreamInterface (which Guzzle does and will continue to do so without a doubt) would lose all of their abstraction over the data source and be forced to dump it into a string wrapped by a PHP temp stream or something similar. On the other hand, libraries that DO use PHP streams in their underlying implementation would just need to wrap the stream with a StreamInterface implementation. Wrapping a PHP stream provides no loss of control to the underlying library; however converting a StreamInterface to a PHP stream loses all control. I'd consider forcing developers to use PHP streams an implementation detail.

What do you (or anyone else)       suggest we use? A type hint that says it can be a string or object that can cast to a string? How would direct consumers of this PSR work with massive payloads that can't fit into memory?

> On Jan 10, 2014, at 9:09 AM, Daniel Lowrey <notifications@github.com> wrote:
> 
> In proposed/http.md:
> 
> > +        array $headers = array(),
> > +        $body = null,
> > +        array $options = array()
> > +    );
> > +}
> > +```
> > +
> > +### 3.7 `Psr\Http\StreamInterface`
> > +
> > +```php
> > +<?php
> > +
> > +namespace Psr\Http;
> > +
> > +/**
> > + * Describes a stream instance.
> No! PSR creates so-called standards for interoperability between frameworks,
> 
> Yes, but this is not the perception in the PHP dev community writ-large and perception is reality.
> 
> keep up the good work (and the StreamInterface)
> 
> As I've said before: StreamInterface is a nice abstraction. However, standardizing it in an "HTTP Message Protocol" with a MUST modifier is a mistake. That's a serious overreach as language-specific internal data structure access and memory-management is totally unrelated to HTTP or HTTP messages.
> 
> Every language *SGI standard of consequence defines requests and responses in terms of native datastructures. See Perl's PSGI, Python's WSGI ... While I'm not advocating storing everything in arrays willy-nilly I'm hopefully pointing out why it's necessary to avoid restricting functionality and putting a ceiling on performance in standards. Otherwise you end up with what PHP web SAPI has now: a slew of frameworks that rate at the very bottom in terms of performance in every available benchmark.
> 
> If PHP frameworks are to stay relevant it won't be because HHVM rescues them from themselves: it will be because they stop enforcing behaviors that limit performance. Interfaces like Message/Request/Response make sense because they don't have native compiled equivalents in the language. PHP already has stream abstractions and requiring StreamInterface as part of a "standard" is a mistake.
> 
> I'm fully in favor of a SHOULD modifier for something like StreamInterface, but its requirement is a mistake.
> 
> —
> Reply to this email directly or view it on GitHub.