Hello. I’d like to share with everyone a discussion started in the slack channel, in order to get more feedback. It’s related with the titles and namespaces used in each Psr, and how we could standarize this. Currently, we have the following standards containing interfaces:
PSR-3 Title: Logger Interface Namespace: Psr\Log PSR-6 Title: Caching Interface Namespace: Psr\Cache PSR-7 Title: Http Message Interfaces Namespace: Psr\Http\Message PSR-11 Title: Container Interface Namespace: Psr\Container PSR-13 Title: Hipermedia Links Namespace: Psr\Link PSR-16 Title: Simple Cache Namespace: Psr\SimpleCache DRAFTS PSR-8 Title: Huggable Interface Namespace: Psr\Hug PSR-14 Title: Event Manager Namespace: Psr\EventManager PSR-15 Title: HTTP Middlewares Namespace: Psr\Http\ServerMiddleware Http-interop namespace: Interop\Http\ServerMiddleware PSR-17 Title: HTTP Factories Namespace: Psr\Http\Message Http-interop namespace: Interop\Http\Factory As you can see, most packages have its own title and namespace, reflecting the purpose of the psr. I think this is good because it’s easy to remember. The exceptions are the http related packages, that are placed inside the Psr\Http\ namespace (instead directly under Psr\). This can be good too, because http is a broad context encompassing many things, some dependent of others. PSR-17 is special, because it’s using the same namespace of PSR-7, but in the Http-interop package uses the namespace Factory (I had not realized until now, writting this email). Which namespace will be choosen finally? PSR-15 is another special case, because, the psr has splitted into two interfaces (Middleware and RequestHandler) and seems that there’s no any descriptive name which may cover these two interfaces. So Psr\Http\Server has been choosen. What will be the title of the namespace, now that is not only Middleware either Request Handler? “PSR-15: Request handler and middleware” or “PSR-15: Server side stuff”? I see some problems with Psr\Http\Server, mainly: - It indicates that the interfaces are for server-side operations, but does not indicate what operations, unlike in the rest of the psr packages. - This forces that other server-side things (as for example, a possible psr for routing), must be placed inside Psr\Http\Server (for coherency), so we have Psr\Http\Server\Router, and so on. - This makes that some psr that can affect to server side, but not exclusively, not use this namespace. For example, in psr-7 we have the ServerRequestInterface, that it’s not in Psr\Http\Server, and in psr-17 the ServerRequestFactoryInterface neither. So, finally we have server-side things outside of the server-side namespace. IMHO, we should standardize this. I think a namespace for each psr, as it was done before is good. If we create a standard for emails, Psr\Email. If we create other for databases: Psr\Database, etc. We could create also a namespace for a broad area, in order to group different Psr related with a specific context, like Http does. But not create a deep namespace structure forcing to place each future interface in different namespace, and avoid things like: - Ok, we created a standard to handle http push notifications - This interface allows to receive push notifications, so it could be placed in Psr\Http\Client - Yeap, but we can send notifications too, so some interfaces should be placed in Psr\Http\Server - Ok, let’s forget about this a create Psr\Http\PushNotifications\ So, for PSR-17, I suggest to use Psr\Http\Factory, (or MessageFactory) because it’s the title of the standard. If anyone want to use this psr, it knows what is the namespace to use. For PSR-15, it’s more complicated, because after the latest change it contains two different interfaces, with different purposes. The best solution, IMHO, is create two PSR: PSR-15: Http Middleware => Psr\Http\ServerMiddleware\ PSR-18: Http Request handler => Psr\Http\ServerRequestHandler\ Other solution suggested was use Psr\Http\ServerStrategy, in order to place here different strategies to handle http server requests, but the word “strategy" can be confused. Having one namespace for each Psr, makes more easy to create new standards and avoid conflicts. This is specially interesting for the FIG, where new standards appear without an initial plan to structure and sort all these things. I guess this is why PSR are numbered incrementally (PSR-0, PSR-1, PSR-2, …) If a new psr replaces other, it must use the same namespace. For example, a future PSR-34 can deprecate a PSR-7, so it use the same namespace (Psr\Http\Message). This is my suggestion. There’re other guys who are disagree with this, so I like to share this in order to read other opinions. Thank you! Oscar Otero. -- 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/DC6F3A04-E8AC-4656-ACE6-77556EB3573F%40gmail.com. For more options, visit https://groups.google.com/d/optout.
