I think he was describing the other interfaces that are part of that proposal. (?)
Since these aren't directly related to the problem at hand, and could be specified in a separate PSR, I'm rooting for a separate PSR for just the handler interface. On May 17, 2017 19:03, "Larry Garfield" <la...@garfieldtech.com> wrote: > On 05/17/2017 09:40 AM, Beau Simensen wrote: > > On Wednesday, May 17, 2017 at 12:42:29 AM UTC-5, Rasmus Schultz wrote: >> >> I think it's great that you're coming around to the idea, Woody :-) >> >> But I am no longer trying to view this as an alternative to PSR-15, >> because, assuming we standardize on that handler-interface first, there is >> nothing about PSR-15 that prevents us from exploring other options. >> > > Indeed, if the end result of this discussion is extracting > DelegateInterface into its own proposal as its own handler interface that > can be used as the delegate in PSR-15, I'm happy with that. > > > I'm still a bit unclear on the "handler" as an uber-generic thing. Isn't > that entirely separate from what Woody described, which is a 3-part > pipeline? (Request modifiers, response modifiers, and request->response > mappers.) > > I admit the 3-part pipeline is appealing, and I've considered it before. > I especially like that it keeps a shallower call stack. However, the > problem is conditional request modifiers. Eg, an Auth modifier that may: > > 1) Add a user token to the request based on authentication. > 2) Fail authentication and short circuit the entire pipeline with a > 401/403 Response itself. > > If the signature only allows returning a Request, then it can't do that. > It has to be a nested mapper instead and do the delegate approach anyway. > And if it's doing that anyway... what's the purpose of having the separate > modifiers if they can't be used half the time anyway? > > I'm afraid I'm still confused here about what is being proposed and what > it solves... > > --Larry Garfield > > -- > 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/B3jtdJA7-6w/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/b7a62479-e587-c7a7-7f1d-b5ddc3464a7d%40garfieldtech.com > <https://groups.google.com/d/msgid/php-fig/b7a62479-e587-c7a7-7f1d-b5ddc3464a7d%40garfieldtech.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_i6iB0OEKTrW5ozehaXCZcGrFoLMKBLcEx0X7ZG%3DOGE%3Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
