> > > This is Symfony's HttpKernelInterface and StackPHP and it has already > been discussed at length > > Same principle, yes, but what I recall being discussed at length was the > lambda-style vs double-pass aspect, which seems unrelated to this > discussion. > > I found one or two older threads on this subject, here's one: > > https://groups.google.com/d/msg/php-fig/Ew36Ng5EwXE/52dAzZAbAQAJ > > The discussion quickly turns to the other, at the time dominant subject > though. >
OK I've started to re-read the mega-thread (https://groups.google.com/forum/#!topic/php-fig/vTtGxdIuBX8%5B101-125%5D - 7 pages long) but most of the debate was indeed about lambda-style/double-pass, and I'm clearly not masochistic enough to read all of it again ^^ So yes maybe we should discuss that (to me it feels like "again" but maybe that's just me). > > I'm not sure why we are starting it all again? > > Are you're saying all of the concerns I described here have been discussed > and are all invalid? > > According to the PSR-15 meta: > > - "There are currently two common approaches to server middleware that use > HTTP Messages", single-pass and double-pass. > > - There's no mention of the fact that HttpKernelInterface doesn't have > the delegate in the interface. > > - The section on "Delegate Design" talks about the design of that > interface, but doesn't say why it exists in the first place. > > I recall there being lengthy discussions about how to name and describe > the delegate interface, but skimming back through the discussion threads > that are listed in the meta, it seems that the discussions all start from > the assumption that a middleware interface has the delegate argument. > So yes even if it was discussed or not, the fact that it lacks from the metadocument is a sign there is something to improve here. My 2 cents about the Stack approach: - AFAIK it didn't work. And it was not tried in some weekend project: it was built on Symfony's interfaces, so pretty solid stuff and it got a good chance for success. On the other hand PSR-7 middlewares were incompatible with most of the existing architectures at the time (incompatible with Symfony for example) and without a standard interface (rather a "callable" convention) and it worked out! So to me that's a clear sign. - it's harder to compose middlewares because they are all nested: the "pipe" pattern was a huge help IMO in spreading the concept - it's harder to write reusable middlewares because you need to standardize the constructor (see the Stack "convention" about the constructor which is less than ideal) - it's harder to wire in DI containers - lazy middlewares are doable but not as easy That's all I have on my mind right now. And we may or may not have discussed it before, but the PHP community has already tried it. That kind of middleware has existed for a long time, and right now what works and what's spreading is not that kind of middlewares. I believe that's because of good reasons and we should not ignore that and start all over again. Matthieu -- 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/b8317921-172a-476c-9df7-5b47e1f089da%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
