On Tuesday, December 5, 2017 11:49:43 AM CST Matthew Weier O'Phinney wrote: > As of today, we formally begin the REVIEW phase of the proposed PSR-15 > (HTTP Server Request Handlers) specification. The proposed > specification is in the fig-standards repository at the following > locations: > > - Specification: > https://github.com/php-fig/fig-standards/blob/52a479b55f5c235ab44aed2254de7e > f1f085982e/proposed/http-handlers/request-handlers.md - Metadocument: > https://github.com/php-fig/fig-standards/blob/52a479b55f5c235ab44aed2254de7e > f1f085982e/proposed/http-handlers/request-handlers-meta.md
*puts on CC member hat* Commentary as I come across it: 1.1: * "as defined by PSR-7". We should learn from PSR-1's PSR-0 reference and say something like "as defined by PSR-7 or subsequent replacement PSRs." Although... Hm, there's no guarantee of exact compatibility there as these are interfaces, not just text. Open to input on this one. * "The type of exception is not defined." - As other specs have done, I'd prefer to see an exception interface that must be included. The exception can be whatever, I suppose, but having an interface to look for to see if it's a handler error is consistent with what other specs have done. 1.2: * "An middleware". Middleware begins with a consonant, so it should be "A middleware". 1.3: * I am not sure how I feel about the PSR-17 mention here. Clearly I agree with the concept, but referencing a still not-passed PSR feels dangerous. Other CC folks, your thoughts? 1.4: * :thumbs up emoji: 2: * Shouldn't the docblock first lines be single-line? I'm totally fine with a much longer description block but the first line should be a short single-line statement. Meta document: 6.2: * "external requests are typically..." External requests is a wonky word to use here. All requests come from something external; that's the whole point. "Outbound requests" seems more descriptive. Otherwise, the Metadoc looks awesome! What I feel is missing is how one would assemble the handler and middleware. My first thought looking at the interfaces and descriptions is "wait, so a middleware can only take a request handler, so that means I can only stack one level deep? That's kinda pointless, unless an object implements both, in which case, erm, how's that work?" I know that the WG has discussed the assembly process to death already and has a good sense of how the pieces "should" be assembled, but from reading the specs I cannot determine what that is. Even if it's just a "one possible way" in the metadoc, there should be some guidance for how one actually leverages the interfaces in practice, although something in the spec itself would be helpful as well. As that would not change the spec, just clarify it, I don't believe that would necessitate coming out of Review state. The other comments above are all fairly minor. (Recall that under FIG 3 the Review state is more of a "beta", not an "RC", so larger changes than typos are fine as long as BC is more or less maintained. Nothing noted above should have any BC implications.) Overall: Aside from that additional guidance, this looks really well done. Nice work, everyone. Once we can get some better guidance included in one or the other documents this would have my vote for passage. --Larry Garfield -- 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/4657045.FTUxf6trKm%40vulcan. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: This is a digitally signed message part.
