Hi Mathew, Thank you for the detailed answer.
Not a native English speaker, so I don't know if I can convince you or others about the same. Writing inline. On Tue, Dec 5, 2017 at 10:38 PM, Hari K T <[email protected]> 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. > I understand your concern about creating a specific exception. For me the wordings > A request handler MAY throw an exception if request conditions prevent it from producing a response. The type of exception is not defined. https://github.com/php-fig/fig-standards/blob/fd9a7669b1b0966fd2fb44d68a3485a1603561f1/proposed/http-handlers/request-handlers.md#11-request-handlers are confusing when the interface not having @throws in the doc blocks . Eg : If you look at the current doc blocks some of us are using @inherit . You may argue this is application level and so it is to the application developer to make the changes to doc blocks. I wanted to express what I felt . > > 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. > I believe we all make some conditions to make it better, so why not the group can make some adjustments to the law ? Are we very strict on this ? Can't the voting members and working group all agree to give a number for this specific issue ? ( Mutual agreements ? ) I don't want to or love to make a delay, I do understand your concern for I have been using Zend-expressive and following some of the discussions around the issue. > 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. > I understand. > 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. > Sure. -- 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/CAESZFtJCz1cJiHY%2B6o0MeDh8%3DnP%2BtN%3DAS7FiDaFnxdoWSof%3DOg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
