> 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 <oscarot...@gmail.com> 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 <ras...@mindplay.dk> 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 <ras...@mindplay.dk>
>> 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 <michael.rou...@gmail.com 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
>>>> 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/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 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/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
> 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/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 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/CADqTB_g3TRuJk28CYiDJTBJS3z5FJvMyAS464VGqYjPqk%2BRODw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
