Hi, Hari! Comments inline below.
On Tue, Dec 5, 2017 at 10:38 PM, Hari K T <kthar...@gmail.com> wrote: > I have send a PR to update the Interface so that throws Exception . > https://github.com/php-fig/fig-standards/pull/975 I've read through that thread. I think the distinction Woody is trying to understand is whether you (or others on the thread) are implying there should be an exception type regarding a "failure to understand the request", or if a request handler should allow bubbling up domain exceptions. My read of what Woody is saying is that domain logic should of course be allowed to raise exceptions, but how a consumer of a handler should handle those is outside the scope of the specification. As an author of a middleware framework, the assumption we've had all along is that any class in the application can potentially throw an exception. As such, we provide exception handler middleware to ensure we're able to log errors as well as return an application response. My feeling on this is: if the specification doesn't explicitly mention a method can or cannot throw an exception, then it's up to the implementation to decide what may or may not be exceptional behavior. In the case of request handlers, I think that's particularly important, as what constitutes a "valid request" may vary widely (does the path need to match criteria? do certain attributes need to be present? etc.), and, most likely, they will be doing domain-specific processing that may not indicate an "invalid request", but could result in exceptional behavior as well. So, my take is: I don't particularly think we should add language around exceptions here, as becoming *more* specific may actually lead to too narrow of an interpretation of what is considered acceptable behavior for an implementation. > One thing I would like to bring is about splitting the current PSR-15 into > two . > > RequestHandlerInterface and MiddlewareInterface as the repos are split into > two. > > https://github.com/http-interop/http-server-handler > https://github.com/http-interop/http-server-middleware > > I think we can all agree to make this happen, so that it will not make the > editors and working group and everyone participated in the PSR not consuming > or dragging the PSR. This idea has been raised a few times, and, no, we cannot all agree to make this happen. This particular proposal set out to standardize *middleware*. While doing that, an argument was made that what we were calling a "delegate" also had more general utility and could potentially be coded to directly. This led to the most recent round of changes, where we renamed the DelegateInterface to RequestHandlerInterface (and also renamed the method defined from "process" to "handle"), and changed the namespace from Psr\Http\ServerMiddleware to the more general Psr\Http\Server. We chose as a working group to honor the idea that the RequestHandlerInterface has its own general utility by splitting the two interfaces into separate packages, with the MiddlewareInterface package *depending* on the RequestHandlerInterface package (as the middleware signature *consumes* a request handler). This allows developers to code directly to the request handler interface without requiring the middleware interface; those who want to consume the primary target of the specification, the MiddlewareInterface, still have all definitions in place in order to create their implementations. An argument has been made that splitting the interfaces into discrete packages may lead to confusion: a package claiming to implement PSR-15 now has to indicate which interface(s) they implement. To be blunt: this will always be the case when there are multiple interfaces defined in a specification. With PSR-7, we have league/uri implementing ONLY the UriInterface. For quite some time, Guzzle did not implement ServerRequestInterface or UploadedFileInterface. Were these PSR-7 implementations? Absolutely. They also clearly indicate what part(s) of the specification they implement within their documentation. With PSR-15, there's a strong liklihood that a developer may only implement MiddlewareInterface or RequestHandlerInterface - particularly in packages that provide middleware implementation(s) (such as the php-middleware project), or in packages such as Diactoros (where we will likely update our Server class to implement the RequestHandlerInterface). Shipping the interfaces as separate packages means that the latter can depend only on the RequestHandlerInterface package, which clearly signals what it implements. Packages that depend on the MiddlewareInterface package will need to document what they implement — which would be true even if the interfaces were defined in separate specifications! Additionally, splitting the RequestHandlerInterface into a separate proposal means delaying this proposal for a minimum of another 3 months, and likely longer, which impacts the libraries that are already attempting to track the proposal and provide implementations. This affects the users of those implementations, as they have uncertainty around what interface(s) to code against, and face potential for migrations in the future. This proposal is already stable; it has been floated for around two years, and the basic workflow has not changed in over a year. It's literally two interfaces, defining a single method apiece. Delaying it longer to accommodate a few people who want more granular proposals, when it's already about as granular as you can get, does a disservice to those already coding against it. Defining both interfaces in a single specification but shipping them as separate packages is a quite reasonable compromise. -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ -- 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/CAJp_myXXc8N3FBGZ5Z46MYiL7rokeekFafRfo3pSr_uQMK4Dgw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
