On Tue, Dec 12, 2017 at 5:12 PM, Larry Garfield <la...@garfieldtech.com> wrote: > On Tue, Dec 12, 2017, at 03:41 PM, Woody Gilk wrote: >> On Mon, Dec 11, 2017 at 10:15 AM, Matthew Weier O'Phinney >> <mweierophin...@gmail.com> wrote: >> > >> > > 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? >> > >> > I tend to agree here. I think we can also make a clarification change >> > here that is not substantive. How about something like this: >> > >> > It is RECOMMENDED that any middleware or request handler that >> > generates a response will either compose a prototype of a PSR-7 >> > ResponseInterface or a factory capable of generating a >> > `ResponseInterface` instance in order to prevent dependence on a >> > specific HTTP message implementation. >> > >> > Woody, thoughts? If there is general agreement, I'll create a pull request. >> >> That seems like a reasonable compromise. > > That resolves the issue nicely, I agree.
Thanks for the word smithing, Larry. This has now been incorporated into https://github.com/php-fig/fig-standards/pull/987 >> > > 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. >> > >> > Considering the follow-up from John Porter, this seems to be a common >> > point needing clarification. I'll see if I can work up something for >> > the metadocument later today. >> >> I think this has been clarified by open PRs on Github. > > Will discuss further on the PR, but I'm looking for something more > substantial than just a line or two. :+1: Continuing the discussion on the PR. > I think that PR also missed a few of the typos I mentioned, so I'm not > sure which I should file PRs for. :-) I'll review again, I thought I had them all. -- Woody Gilk http://about.me/shadowhand -- 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/CAGOJM6KVqaw%2Bp%3D0wLurzbZ8zmXg_4AjJ_WcBH-i3RAz%3DNS902A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
