Terminology

[mindplay-dk]

Okay, so the first thing I'd like to clear up, is the terminology.

We've dubbed the PSR "HTTP Request Handler", so why all this other terminology?

Specifically the term "Action" - combined with "Request Handler" as e.g. "Request Handler Action" in the specification section, why the additional term "Action"?

It seems superfluous.

This section makes it sound like this PSR defines two different things, and I can't make sense of the second bullet-point at all:

A Request Handler Action encapsulates all information needed to perform the behavior of a Request Handler

I'm not sure what that means.

I'd suggest reducing section 1 to simply:

This specification defines a general, high-level contract for a server-side Request Handler: a component that accepts a PSR-7 ServerRequestInterface instance and returns a PSR-7 ResponseInterface instance.

No bullet points, no further descriptions, because it really is that trivial - in my opinion, trying to come up with a more detailed description will most likely only muddy the waters and add confusion. This is a very simple PSR, so we should keep the description of it simple - justification etc. can go in the meta.

[schnittstabil]

so why all this other terminology?

It was the first attempt, not thoroughly considered.

A Request Handler Action encapsulates all information needed to perform the behavior of a Request Handler

I'm not sure what that means.

The intended meaning is similar to the one of the Command Pattern:

command pattern is a behavioral design pattern in which an object is used to encapsulate all information needed to perform an action or trigger an event at a later time.

The current interface (because of __invoke) does not model the request handler itself, it modelse the action a request handler performs.

[mindplay-dk]

command pattern is a behavioral design pattern in which an object is used to encapsulate all information needed to perform an action

But this is not (necessarily) that.

We can't stipulate that a single object is used to encapsulate all information - it's most likely multiple objects, such as in the known case of middleware dispatchers, which are composed of many objects.

We also can't stipulate this be the only method implemented by the same class.

Even if the implementation happens to be just a single object with just one method, the method requires a Request argument, so, by definition, the object does not have all the data required - it still needs a Request instance, so it's command-ish, maybe, but it's not the command pattern.

Even if it resembles one or more patterns, it's not really our job to teach patterns - we only need to describe the purpose of the simple interface enabling the request/response-exchange described by the PSR itself.

Since you mention __invoke, that's another issue, but I thought you already previously agreed not to pursue that approach? I think it would be extremely unorthodox to do this in a PSR, since it could collide with any other future PSR that chooses to do so - I don't think that's a good precedent to set.

Do we have to go through all of the discussions we've already had again? It kind of seems like this PSR starts back from where we were before all of those lengthy discussions. Wouldn't it make more sense to start from the conclusions we already arrived at, and then work from there, rather than starting from square one again?

[mindplay-dk]

Looks like the middleware proposal is adopting the term "handler", and I think this proposal should too. The term "handler" is used in the name of this proposal/package anyhow, and hopefully this change will enable us to sync up with the middleware proposal very soon, so they don't end up including their own definition of that same interface.

The method name remains still as process() in the middleware proposal - again, I'd like to propose we move past this debate, sync up, and finish this proposal soon. (I'm concerned the middleware proposal may simply move ahead and ignore this proposal if we don't move on this soon.)