Naming of DelegateInterface in light of #45

[weierophinney]

45 updated DelegateInterface to typehint its $request argument against the PSR-7 ServerRequestInterface instead of RequestInterface, as recent discussions have concluded that http-middleware/PSR-15 should only target server-side middleware.

To my mind, this now raises a question about naming consistency: the middleware interface is ServerMiddlewareInterface, the namespace is Psr\Http\Middleware, and the delegate, though it typehints against ServerRequestInterface, is only named DelegateInterface.

As such, I propose we take one of the following courses of action:

1. Rename the namespace to Psr\Http\ServerMiddleware, and rename the ServerMiddlewareInterface to MiddlewareInterface.
2. Rename DelegateInterface to ServerDelegateInterface.
3. Do nothing; make no further changes.

Either of these would make the naming more consistent. The first would allow a later PSR addressing client-side middleware to live in a separate namespace, keeping them parallel but separate. The second would allow such a PSR to re-use the same namespace, but using a prefix such as Client on the interfaces it defines.

The third, of course, requires no effort, but could lead to questions or confusion by implementors and/or consumers later.

I personally prefer either the first or second option, but have no preference between them; I mainly would like to see which approach is favored by others.

[schnittstabil]

4. Psr\Http\Server\MiddlewareInterface and Psr\Http\Server\DelegateInterface

If someone wants to mix client and server they can use aliases – but I do not think that will happen often…

[atanvarno69]

I would prefer option 1 or 2, and think it's largely an aesthetic choice between them. Given that, I'd prefer option 1, since I like shorter interface names.

Edit: or option 4, for the same reason.

[weierophinney]

@schnittstabil I think Psr\Http\Server is misleading, as it implies that the code beneath it is capable of providing an HTTP server. By including Middleware in the namespace, we properly indicate the purpose of the code beneath it. (This is, of course, why PSR-7 uses the Message sub-namespace, versus simply being in the Psr\Http namespace.)

[schnittstabil]

@weierophinney 4. was just missing in your list. I do not really like Psr\Http\Server\….

[schnittstabil]

I believe we should/must align with PSR-7 in some way:

use Psr\Http\Message\MessageInterface;
use Psr\Http\Message\RequestInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Message\ClientRequestInterface; // maybe with PSR-77
use Psr\Http\Message\FooRequestInterface;    // maybe with PSR-Foo

Any {Message, Request, ServerRequest, ClientRequest, …}MiddlewareInterface could be useful at some day.

Side note about ClientRequestInterface: PSR-7 does not provide a request interface fully dedicated to the client side (RequestInterface fails because of the inheritance hierarchy in PSR-7).

[schnittstabil]

Maybe 5.:

use Psr\Http\Middleware\Server\MiddlewareInterface;
use Psr\Http\Middleware\Server\DelegateInterface;

use Psr\Http\Middleware\Client\MiddlewareInterface;
// … more client related middleware interfaces

use Psr\Http\Middleware\Foo\MiddlewareInterface;
// … more foo related middleware interfaces

[schnittstabil]

Or if we think about asset pipelines etc. Maybe a variation of 6.:

use Psr\Middleware\Server\MiddlewareInterface;
use Psr\Middleware\Server\DelegateInterface;

use Psr\Middleware\Client\MiddlewareInterface;
// … more client related middleware interfaces

use Psr\Middleware\Assets\MiddlewareInterface;
// … more asset related middleware interfaces

[oscarotero]

I like 1, because it's meaningful:

• Psr\: This is the vendor
• Http\: This is the area in which we are working
• ServerMiddleware\: This is the recommendation name
• MiddlewareInterface | DelegateInterface: The interfaces

Note that only PSR-7 use these three namespaces (Psr\Http\Message), the rest of the PSR use only two (the area is skipped), for example Psr\Cache, Psr\Link, or the comming up Psr\Container, Psr\SimpleCache, etc. Maybe this makes sense because Http is an area that contains serveral recommendations interconnected and the others are more independent (with the exception of Cache, that Psr\SimpleCache might be renamed to Psr\Cache\Simple.