Practical reasons to divide this repository?

[devgkz]

Tell please, Why this repository was divided into two (http-interop/http-request-handlers and http-interop/http-server-handler)? Can you give example use cases?

[shadowhand]

http-server-handler is a general purpose interface that can be used anywhere, not just in middleware. http-server-middleware depends on it for obvious reasons.

[devgkz]

Thank you!

[mindplay-dk]

So the repository has been divided into two packages, but the PSR is still one specification.

That means the packages are actually incomplete/fragmented/partial implementations of the specification.

So I can install a part of the PSR, and support part of the specification, but you'll need to specify in prose which portion of the PSR your package complies with.

It doesn't really make any sense.

It would make a lot of sense, if these were separate PSRs, like some of us were pushing for.

[danizord]

@mindplay-dk I can't see any problem with packages that implements a subset of PSR interfaces. PSR-7 provides 6 interfaces and you don't need to implement them all, for instance https://github.com/thephpleague/uri implements only the UriInterface and that's fine.

Actually the only problem is that https://github.com/thephpleague/uri consumers have to download all the PSR-7 interfaces even if they are not using it. Shipping interfaces in separate packages fixes that problem :)

[weierophinney]

@mindplay-dk — The fact of the matter is that:

• If you only require psr/http-server-handler, you are indicating you are either only consuming or implementing that particular interface.

• If you require psr/http-server-middleware, you are indicating you are either consuming or implementing the MiddlewareInterface, and consuming the RequestHandlerInterface. The only question at that point is if you are implementing the RequestHandlerInterface. This question would be true regardless of whether or not we split the interfaces into separate specifications, as http-server-middleware depends on http-server-handler, and developers may choose not to explicitly require the latter even if they implement it, as they know it is a requirement of the former.

One change we could make to the specification is that if a library will be implementing RequestHandlerInterface it SHOULD also require the package defining it, as a way to message that it implements it.

That said, I think that's a false presumption: As noted in the first bullet point above, requiring the package does not in any way indicate the library implements the interface; it may only consume it.

My point is: packages already need to indicate the context for requiring either package. Is that context consumption? Is it implementation?

Further, there's discrete verbiage in this specification: developers will be indicating they provide middleware, or provide a request handler, or provide a middleware dispatcher, etc. This verbiage is descriptive and understandable already. With only two interfaces, each with a single method apiece, and clearly defined roles, I do not anticipate much confusion.

[mindplay-dk]

I understand all of that, but you both misunderstood what I said:

That means the packages are actually incomplete/fragmented/partial implementations of the specification.

I'm not talking about your packages - I'm talking about the two packages that implement (define/declare) the PSR specification itself.

My problems is two packages for one specification: that's not separation, it's fragmentation.

If the PSR itself was two PSRs with separate specifications, it would make sense - but as things stand, PSR-15 is currently two specifications, one completely independent of the other, so we have two specifications rolled into one.

I find that problematic, and clearly I'm not the only one - I view the separation of one specification into two packages as a symptom of PSR-15 being actually two specifications in one.

[oscarotero]

I understand. So you're suggesting to create two PSR specification (for example PSR-15 for middlewares and PSR-N for server-request-handler), right?

[mindplay-dk]

Yup.

If you wanted two degrees of API separation (which I and others have been pushing for the past year) then we should have had two separate PSRs as well.

I know this complicates the process, and everybody wants to finish - but I can't help but view the separation into two packages as acknowledgement that this should have been two separate specifications.

Either that, or go back to a single package and avoid the confusion of the extra package which doesn't align with the single PSR. The downside to this, is that package authors may need to describe in prose which part of the PSR they comply with.

Frankly, at this point, I'm fine with it either way - but IMO if you're going to separate the package, you should also separate the PSR.

[shadowhand]

I feel that this is entirely unnecessary. @mindplay-dk you pushed for having separate packages so that packages that only provide a request handler implementation wouldn't need to depend on middleware package. That makes sense, so we have two separate packages.

In my mind, the split is totally clear:

• if you are providing a middleware, you depend on http-server-middleware
• if you are providing a request handler, you depend on http-server-handler

[shadowhand]

And frankly, suggesting that an entirely new PSR process should be started at this point is awful timing. This has already taken a year or more longer than it should have, and I think everyone in the working group is happy with the place we have arrived at. To start a new working group, which would completely block all progress on PSR-15 is not an acceptable situation to me.

[devgkz]

I am experimenting with middleware applications and find this approach excellent. My reason of having one package was convenience initially. I think about it from the application-level abstraction as a consumer. Interfaces consisting of a few lines of code has no overhead. But has complete PSR-15 specification in one package.

At the moment, I think that two separated packages are also quite convenient. I can develop applications with middleware pipes and using http-server-middleware. Or develop applications with one step (one level) request handler and using http-server-handler... It's ok.

We really need the stable and approved PSR-15 specification now. For develop awesome applications and accumulate achievements, rather than wasting time to support version compatibility.

[devgkz]

I hope the specification will be approved soon. Finally, one more question. After the specification is approved, will the package names be changed again as it was with psr/container (ex. container-interop)?

[shadowhand]

After the specification is approved, will the package names be changed again

That's correct, we'll be doing the same thing as container-interop, where psr/* packages will be created and this package will switch to depending on the psr/* package.

[mindplay-dk]

you pushed for having separate packages so that packages that only provide a request handler implementation wouldn't need to depend on middleware package

@shadowhand I pushed for two separate PSRs - as explained above, splitting a single PSR over two packages would not have been my choice. Please don't put that on me.