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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ebb0c129-034e-401b-9e55-91becd182b00%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
