About the LateStreamInterface proposal

[Lcfvs]

Hi all,

I just sent a proposal to add an interface to describe a late stream, which doesn't requires an already opened resource.

For the proposal, see https://github.com/php-fig/http-message/pull/82

As said by Jean85:

This is a completely non-trivial change to the spec, and also not an errata. I would say that you should push for this change opening a discussion on the PHP-FIG mailing list...

... then I'm here. :D

My motivation is about the

• server limitations (max opened files)
• performances in case of unused streams
• the ability to get a stream of broken uploaded file
• ...

Indeed, it isn't an errata, I made it to avoid any breaking changes, it's why a new interface.

What do you think about it?

[Lcfvs]

Another question, I made some typo fixes... May I push them or to wait more discussion before ?

[Larry Garfield]

On Wednesday, October 31, 2018 5:01:25 AM CDT Lcfvs wrote:
> Hi all,
>
> I just sent a proposal to add an interface to describe a late stream, which
> doesn't requires an already opened resource.
>
> For the proposal, see https://github.com/php-fig/http-message/pull/82
>
> As said by Jean85:
>
> This is a completely non-trivial change to the spec, and also not an
>
> > errata. I would say that you should push for this change opening a
> > discussion on the PHP-FIG mailing list...
>
> ... then I'm here. :D
>
> My motivation is about the
>

> - server limitations (max opened files)
> - performances in case of unused streams
> - the ability to get a stream of broken uploaded file
> - ...

>
> Indeed, it isn't an errata, I made it to avoid any breaking changes, it's
> why a new interface.
>
> What do you think about it?

This is a very non-trivial change, and thus out of scope for the spec. This
will never be part of PSR-7. It would require a new PSR to add it.

--Larry Garfield

[Matthew Weier O'Phinney]

I think it's quite interesting, but any substantive change - which includes additions and removals — requires either errata or a new PSR. Generally errata are reserved for changes to the existing interfaces and/or narrative, while additions and removals require new PSRs.

Honestly, we need to likely update PSR-7 to PHP 7.1, to allow for scalar and return type hints, which also requires a new PSR, and this would fit in that nicely.

--

Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Lcfvs]

Thanks guys, for these first advices. :)

If you make a PSR-7 "bis", maybe it can merge it with the current StreamInterface, to have that behavior by default, no ?

I'm strongly interested about it, currently making a new framework.

Actually, I use mine, extending the PSR-7 but if I can avoid ^^

[Woody Gilk]

I don't see what the value of this is. The reasons stated:

> server limitations (max opened files)

Often streams are php://memory (though it depends on PSR-7 implementation) and therefore not subject to max opened files limit.

> performances in case of unused streams

Memory streams, and even temporary file streams, contribute approximately 0% overhead to a typical request load.

> ability to get a stream of broken uploaded file

What value does this have? If it's broken, it probably should not be inspected for security reasons.

The StreamInterface is the one interface about PSR-7 that I don't care for, but I don't see what value this change would have.

--
Woody Gilk
https://shadowhand.me

On Wed, Oct 31, 2018 at 5:01 AM Lcfvs <michael...@gmail.com> wrote:

--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/d91f9110-92d5-4721-8c9c-fcf0a1ada7ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lcfvs]

I don't see what the value of this is. The reasons stated:

> server limitations (max opened files)

Often streams are php://memory (though it depends on PSR-7 implementation) and therefore not subject to max opened files limit.

Often is not all, IMHO, the streams, as defined by the PSR-7 doesn't have any usage limitations, it to read any resource. Seriously, I really seen that bug to a previous employer. It's easy to avoid it, then why not?

 

> performances in case of unused streams

Memory streams, and even temporary file streams, contribute approximately 0% overhead to a typical request load.

Memory is a point, but open a resource has also a cost in time. Avoid them both if possible, even if it's a few.

 

> ability to get a stream of broken uploaded file

What value does this have? If it's broken, it probably should not be inspected for security reasons.

If you look in the PSR-17, it requires a stream as first parameter, send with the error code.

Then if I don't interpolate too much, the error code must be checked, if it always equals to UPLOAD_ERR_OK to create a stream, that parameter is fully useless.

[Lcfvs]

And as bonus, the same stream can be reopened. :)

[Martijn van der Ven]

It may just be me, but what does that proposal add that isn’t currently accessible to us in the existing PSRs?

withFilename, withTmpFile, and withResource all returning a new Stream instance feels like they match pretty closely with PSR-17’s createStreamFromFile, createStream, and createStreamFromResource, respectively. Then the “late stream” part feels like an implementation detail of Stream, where a resource is only opened when the user acts on it.

Even if it is important enough to be able to separate normal (whatever that means) Stream from LateStream instances, would it not make more sense to put these with* methods in a factory?

What use do you envision the open method to have? Clearly we wouldn’t want users to have to call it before calling any other methods. And if the other methods must include this functionality anyway, why make it callable by the user at all?

I really do like the idea of using a Stream implementation that postpones file io as long as possible. I am mostly just baffled about the need for this new interface, so hopefully you can put forth some of the reasons why this can’t be done with the current PSRs :)

[Lcfvs]

Actually, I made it in a new interface to avoid breaking changes, because the actual implementations probably doesn't postpone the io. But, in fact, I'm convicted they can merge.

For the open method, it can be used by implementations to use it to add some other methods (truncate, unlink, move, rename, etc.).

[Nicholas Ruunu]

It may just be me, but what does that proposal add that isn’t currently accessible to us in the existing PSRs?

I agree with Martijn, I actually outlined the same things in the Github PR.

Actually, I made it in a new interface to avoid breaking changes, because the actual implementations probably doesn't postpone the io. But, in fact, I'm convicted they can merge.

As Martijn said, this is an implementation concern, not a contract concern. It's up to the implementation to make it lazy or not.

For the open method, it can be used by implementations to use it to add some other methods (truncate, unlink, move, rename, etc.).

You can already do this without the open method if your implementation is lazy.