> Can we confirm that these always allow the pointer to be set to position zero?
I assumed this was just common knowledge? I've never heard of a stream-wrapper that doesn't open streams with the file-pointer at zero - I'm pretty sure that's implied, if it isn't specified. (and I'd be surprised if it doesn't have test-coverage in the code-base somewhere.) > None of the emitters linked would be affected by changes to the pointer position as none of them call read() Here are just two that I happen to know of: https://github.com/narrowspark/http-emitter/blob/master/src/SwooleEmitter.php#L94 https://github.com/zendframework/zend-httphandlerrunner/blob/master/src/Emitter/SapiStreamEmitter.php#L72 I'm pretty sure there are more - I couldn't find it, but I'm pretty sure I've seen an emitter for ReactPHP as well. Basically anything that doesn't emit by the usual means (standard output) will have to read the stream. I've opened a PR with my proposed amendments here: https://github.com/phpDocumentor/fig-standards/pull/170 Regarding the 4th change you're proposing, that would be an amendment to PSR-7, which I believe goes beyond the scope of this discussion and my proposed amendment. I am also not convinced it makes sense to propose an amendment to PSR-7 that references the PSR-17 specification? I don't want to conflate my own proposed amendment with a PSR-7 issue - if you want to propose an amendment to address the issue with PSR-7, I think that would make sense, but I think it needs to be described independently of PSR-17 and I'd suggest you open a separate discussion and a separate PR, since, while the topics are related, the changes do not pertain to the same PSR. On Thursday, January 10, 2019 at 1:09:12 PM UTC+1, Martijn van der Ven wrote: > > It sounds like an errata is possible still? That is good to hear! I am not > particularly familiar with the bylaws. > > [Diactoros] leaves streams created from a file path with the pointer at >> zero: >> > > This is a bit of an overstatement IMO. It does not set the pointer to > zero, instead it leaves the pointer untouched from where fopen() puts it. > For local files this seems to be at zero, but I am not sure if this is > actual documented behaviour. I could not find it in the PHP documentation, > but it may just be default handling by C’s fopen()? > > It may also be worth noting that many implementations simply map > createStreamFromFile() to fopen() and thus allow URLs that have registered > protocol handlers (PSR-17 calls these “stream URI”). Can we confirm that > these always allow the pointer to be set to position zero? (Or always > default to that position?) If we cannot, requiring that implementations > MUST put the pointer at zero will simultaniously mean createStreamFromFile > can no longer map straight to fopen(). > > It is because of this mapping, and the many references PSR-17 already > makes to fopen(), that I wondered in my very first email whether the cursor > position should be defined as having to match fopen()’s cursor position. > This is also how I proposed testing it: > https://github.com/http-interop/http-factory-tests/pull/39/commits/ca49679370c6b22bf8b3544c71e0a4a338c9cb8a > > Emitters of existing libraries do not rewind streams: […] >> >> Introducing a requirement to move the file-pointer to the end when >> creating a stream from a file path is a serious breaking change versus any >> existing emitter implementation I could find - so mandating a change at >> this point could create serious problems. >> > > None of the emitters linked would be affected by changes to the pointer > position as none of them call read(), instead having chosen to depend on > the defined behaviour of __toString from PSR-7. This definition includes > the fact it “MUST attempt to seek to the beginning of the stream before > reading data” so calling rewind() isn’t neccessary from those emitters’ > perspective. > > No matter what cursor position ends up in a possible PSR-17 errata, those > emitters will continue to function without issue. > > And __toString() is absolutely not an option in the case of an emitter, if >> you're going to send large binary files. >> > > If you have come across emitters in your search that support this, and > thus depend on read() calls rather than __toString(), would you mind > sharing them? Those will obviously be affected by any change that might be > decided upon. I have not personally been able to find any. > > Two of the three stream factory-methods defined by PSR-17 *create* the >> stream, and therefore it's important to know what state they're created in >> - […] what use is a factory that returns objects in an >> undefined/unpredictable state? >> > > Agreed. The unpredictable outcome of a factory method is the main reason I > started researching this behaviour, and why I wanted to prioritise getting > tests into http-interop/http-factory-tests. > > There is one more creation point that may need consideration: > > (new ResponseFactory)->createResponse()->getBody()->write() > > I have seen code like that in many places, and it will offload the > creation of a Stream to the message factories or even the underlying > (PSR-7) message implementations. This seems to be done mostly as a way of > skipping the StreamFactory completely. So maybe it needs to be defined that > the creation of a default stream for these cases always matches > createStream('')? From code I have seen the expectation is for it to be an > empty and writeable stream, which matches the default createStream(). > > All together I would think of changes more along the lines of: > > > 1. StreamFactoryInterface::createStream() MUST return a stream with > the internal file-pointer at 0. > 2. StreamFactoryInterface::createStreamFromFile() MUST return a stream > with the internal file-pointer matching fopen()’s internal file-pointer, > alternatively at 0. > 3. StreamFactoryInterface::createStreamFromResource() MUST NOT modify > the internal file-pointer. > 4. Streams created as defaults for MessageInterface::getBody() MUST > match StreamFactoryInterface::createStream(''). > > > Cheers, > Martijn > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/519e8f06-7c63-4192-8c05-5cb610b46bc7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
