I've updated my PR with this commit: https://github.com/php-fig/fig-standards/pull/1134/commits/983002eb09fb961bccb0c77250e39af498c313be
Thanks for bringing this up, Oscar! Glad you caught this :-) On Tuesday, January 29, 2019 at 5:01:00 PM UTC+1, Oscar Otero wrote: > > Yes, I think that expresses it very well. > > On Tue, 29 Jan 2019 at 16:51, Rasmus Schultz <[email protected] > <javascript:>> wrote: > >> > The spec should focus only in the fact that, any new stream created >> with PSR-17 (directly using $streamFactory->createStream() or though a >> request or response message) must be empty and writable. >> >> Okay, so just this then? >> >> "The created instance MUST return an empty body-stream in read/write >> mode." >> >> (please suggest exact wording if you disagree.) >> >> >> On Tue, Jan 29, 2019 at 10:43 AM Oscar Otero <[email protected] >> <javascript:>> wrote: >> >>> Hi. To me, this is a problem of PSR-17, not PSR-7. >>> What I'm asking is being sure that whenever I create a new response, I >>> can write the body: >>> >>> $response = $factory->createResponse(); >>> $response->getBody()->write('Ok'); >>> >>> Errors like "Fatal Error - Too many open files" are out of scope because >>> it's an implementation detail. We can create an implementation not using >>> streams at all (just use a variable containing the string). The spec should >>> focus only in the fact that, any new stream created with PSR-17 (directly >>> using $streamFactory->createStream() or though a request or response >>> message) must be empty and writable. >>> >>> On Tue, 29 Jan 2019 at 08:42, Rasmus Schultz <[email protected] >>> <javascript:>> wrote: >>> >>>> How about this wording? >>>> >>>> "The created instance MUST return a body an empty body-stream in >>>> read/write mode (e.g. `fopen('php://temp', 'rw+')`) and SHOULD defer the >>>> creation of body-streams to conserve system resources." >>>> >>>> Under all three sections. >>>> >>>> And then a short section in the meta-document summarizing why and how >>>> to defer the creation of file-system handles. >>>> >>>> Sound good? >>>> >>>> >>>> On Tue, Jan 29, 2019 at 6:26 AM Rasmus Schultz <[email protected] >>>> <javascript:>> wrote: >>>> >>>>> Yikes, I didn't know about this issue. >>>>> >>>>> To others who don't know what this is about, this thread has some >>>>> information: >>>>> >>>>> https://github.com/guzzle/guzzle/issues/1927 >>>>> >>>>> TL;DR Linux has a default limit of 1024 open file handles at the OS >>>>> level. >>>>> >>>>> Okay, but... >>>>> >>>>> This can't become a choice between an incomplete model or a model that >>>>> can't scale. Both are unacceptable. >>>>> >>>>> The only sensible recourse I can think of, is we need special >>>>> TempStream implementation that doesn't open an actual file handle until >>>>> you >>>>> write to it. >>>>> >>>>> I think we could put this as a recommendation in the PSR? It's an easy >>>>> work around. >>>>> >>>>> Another possible work around is a custom stream implementation that >>>>> uses a simple string as buffer. >>>>> >>>>> Of course, this approach only works up to a certain file size, but you >>>>> could further optimize by switching to a temp-stream when the buffer hits >>>>> a >>>>> certain size limit or somebody tries to detach the resource handle. >>>>> >>>>> Yet another option is to lazy initialize in getBody() ... >>>>> >>>>> So there are ways to work around this. >>>>> >>>>> I don't think returning an incomplete, unusable model an acceptable >>>>> solution. >>>>> >>>>> For one, the type-hint of getBody() is StreamInterface, it's not >>>>> StreamInterface|null >>>>> - so you have to return an instance or you're not complying with the >>>>> original spec in the first place. >>>>> >>>>> This is a lot of information to put in an amendment though 🤔 >>>>> >>>>> On Tue, Jan 29, 2019, 04:42 Lcfvs <[email protected] <javascript:> >>>>> wrote: >>>>> >>>>>> Le lundi 28 janvier 2019 12:57:49 UTC+1, Rasmus Schultz a écrit : >>>>>>> >>>>>>> "Implementations of this interface MUST initialize the body stream >>>>>>> with an empty temp-stream in read/write mode, e.g. fopen('php://temp', >>>>>>> 'rw+')" >>>>>>> >>>>>> >>>>>> Like I already said on this group, open a stream, by default, for >>>>>> everything like this increases the risk to reach the "Fatal Error - Too >>>>>> many open files". >>>>>> >>>>>> I strongly disagree that, please don't make it a >>>>>> requirement/recommandation! >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to a topic in >>>>>> the Google Groups "PHP Framework Interoperability Group" group. >>>>>> To unsubscribe from this topic, visit >>>>>> https://groups.google.com/d/topic/php-fig/mv9-MWDVVBM/unsubscribe. >>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>> [email protected] <javascript:>. >>>>>> To post to this group, send email to [email protected] >>>>>> <javascript:>. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/php-fig/7123beae-3ac4-4062-b4dc-bb29effa90fa%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/php-fig/7123beae-3ac4-4062-b4dc-bb29effa90fa%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>> 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] <javascript:>. >>>> To post to this group, send email to [email protected] >>>> <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/php-fig/CADqTB_i8MZoNLDBhLQcmHpT4h6HbRyks%3D227h9BdiHKjstVrhQ%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/php-fig/CADqTB_i8MZoNLDBhLQcmHpT4h6HbRyks%3D227h9BdiHKjstVrhQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "PHP Framework Interoperability Group" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/php-fig/mv9-MWDVVBM/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/php-fig/CALrFU9WaL-jXvguq8Fu0Hh%3DtuwKN%3DDfK4tt2_64JEwWc6%3DNhrQ%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/php-fig/CALrFU9WaL-jXvguq8Fu0Hh%3DtuwKN%3DDfK4tt2_64JEwWc6%3DNhrQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/CADqTB_g3TRuJk28CYiDJTBJS3z5FJvMyAS464VGqYjPqk%2BRODw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/php-fig/CADqTB_g3TRuJk28CYiDJTBJS3z5FJvMyAS464VGqYjPqk%2BRODw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/4a254e11-ea95-4527-87e5-9da1738ce3a9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
