Namespace of all packages

[joelwurtz]

I would like to propose the following namespace for our different package (goal is to have, in the future, possibility to assemble all package into a single one with subsplit):

• Httplug : Http\Client (not changed)
• Promise : Http\Promise (not changed)
• Message-Factory: Http\Message (not changed)
• Tools : Http\Tools (Http\Client\Tools actually)
• Utils : Http\Utils (Http\Client\Utils actually)
• Plugin : Http\Plugin (Http\Client\Plugin actually)
• Adapters (guzzle / react / ...) : Http\Adapters\[Adapter Name], so Guzzle6 will have this namespace for example : Http\Adapters\Guzzle6 (instead of Http\Adapter actually)
• Clients (socket / curl / ...) : Http\Clients\[Client Name], so Socket will have Http\Clients\Socket
• Discovery : Http\Discovery (not changed)

WDYT ?

[sagikazarmark]

Looks good to me.

One comment: Plugin seems to be a bit inconsistent with the other namespaces, which are mostly plural (in case of a collection instead of one, separated component).

[joelwurtz]

So Http\Plugins then ?

[sagikazarmark]

Sounds logical to me 😄

[joelwurtz]

pinging client / adapters maintainers since it concerns them a lot @mekras @shulard @Nyholm @ddeboer WDYT ?

[dbu]

👍

[shulard]

Hello!

For me your proposal is a lot cleaner than the actual one! 👍

Le 19 déc. 2015 à 21:14, Joel Wurtz notifications@github.com a écrit :

pinging client / adapters maintainers since it concerns them a lot @mekras @shulard @Nyholm @ddeboer WDYT ?

—
Reply to this email directly or view it on GitHub.

[jeromegamez]

I spent hours writing this comment, so it might be that some of my thoughts got mingled. If you take something out of this, let it be two things: we have too many repos, and these are really nicely formatted tables :D.

Overview of current repos

Repo	Description	Namespace	Scope
authentication	Authenticate PSR-7 requests	Http\Authentication	Message
client-tools	Tools for HTTPlug client implementors	Http\Client\Tools	Client
cookie	Simple Cookie container logic for HTTP Requests	Http\Cookie	Message
curl-client	cURL client	Http\Curl	Client
discovery	Finds installed adapters and message factories	Http\Discovery	Adapter/Message
encoding	PSR 7 Stream for transfer / content encoding headers (chunked, deflate, compress, ...)	Http\Encoding	Message
guzzle5-adapter	Guzzle 5 HTTP adapter	Http\Adapter	Adapter
guzzle6-adapter	Guzzle 6 HTTP adapter	Http\Adapter	Adapter
helper	Helper classes for HTTP related data	Http\Helper	Message
httplug	HTTPlug, the HTTP client abstraction for PHP	Http\Client	Client
message-decorator	Decorators for PSR-7 HTTP Messages	Http\Message	Message
message-factory	Factory interfaces for PSR-7 HTTP Message	Http\Message	Message
mock-adapter	Mock HTTP Adapter for testing	Http\Adapter	Adapter
plugins	Plugin client, decorate http client with middlewares	Http\Client\Plugin	Client/Message
promise	Promise used for asynchronous HTTP requests	Http\Promise	message
psr7-vcr	Not even started yet (mea culpa :))	(none)	Client
react-adapter	(no description)	Http\Adapter	Adapter
socket-client	Socket client	Http\Socket	Client
utils	HTTP Client Utilities	Http\Client\Utils	Client/Message

Suggested changes

With this categorization in mind, I would like to suggest the following changes.

Overall: From php-http/utils, I would use just one message factory, either zend-diactoros or guzzle/psr7 - any PSR-7 compliant HTTP Client should be able to work with either of these. Both have no special dependencies, so this should just be a matter of decision.

Message-related repos

Suggestion: Merge all repos into one, e.g. php-http/message.

Reasoning: It could of course be that I want to create messages with the factory, but I don't need authentication or a special stream, but the single components don't disturb each other. At the moment, if I wanted to create an authenticated HTTP Message with Cookies, I would have to require

Repo(s)	Current Namespace(s)	New Namespace
authentication	Http\Authentication	Http\Message\Request\Authentication
cookie	Http\Cookie	Http\Message\Request\Cookie
encoding	Http\Encoding	Http\Message\Stream
helper	Http\Helper	Http\Message\Helper Http\Message\Helper\Extractor Http\Message\Helper\Normalizer Http\Message\Helper\Parser
message-decorator message-factory utils(parts)	Http\Message	Http\Message\Factory Http\Message\Factory\Decorator Http\Message\Factory\MessageFactory Http\Message\Factory\StreamFactory Http\Message\Factory\UriFactory
promise client-tools(parts)	Http\Promise	Http\Message\Promise Http\Message\Promise\FulfilledPromise Http\Message\Promise\RejectedPromise

Client-related Repos

Repo	Current Namespace	New Namespace
httplug	Http\Client	Http\Client
batch-client (extracted from utils)	N/A	Http\Client Http\Client\BatchClient (class)
client-tools	Http\Client	Http\Client\Tools
curl-client	Http\Curl	Http\Client Http\Client\CurlClient (class) (shouldn't this be an adapter?)
plugins	Http\Client\Plugin	Http\Client\Plugin
socket-client	Http\Socket	Http\Client Http\Client\SocketClient (class) (shouldn't this be an adapter?)
vcr-client/psr7-vcr	N/A	Http\Client Http\Client\VcrClient (class)

Adapter-related repos

Repo	Current Namespace	New Namespace
curl-adapter?	N/A	Http\Adapter\Curl
guzzle5-adapter	Http\Adapter	Http\Adapter\Guzzle5
guzzle6-adapter	Http\Adapter	Http\Adapter\Guzzle6
mock-adapter	Http\Adapter	Http\Adapter\Mock
react-adapter	Http\Adapter	Http\Adapter\React
socket-adapter?	N/A	Http\Adapter\Socket

[sagikazarmark]

Wow @jeromegamez I cannot find words to describe this. 😄 👍

The fact that we have too many packages came up a few times already. There are upsides and downsides of both the single repo and the multi repo solution.

but the single components don't disturb each other.

This is true, but I would at least partially modify this statement: I would exclude contracts and limit to implementations.

Contracts are probably better to keep somewhat separated so that you can require them without implementations, which is useful when you want to implement your custom stuff.

I would use just one message factory, either zend-diactoros or guzzle/psr7

I am not sure I understand this. Should we support only one? That's not really interoperable.

shouldn't this be an adapter?

Well, as you originally proposed in April when we started the whole thing, we are actually working on an HTTP Client abstraction, not an apdater one. So when we implement something new, then it is actually a client. When we implement a wrapper something already existing, then it's an adapter.

To tell the truth, the most useful proposal from your comment is the message thing for me. Message related stuff is really spread across many repositories. With the following modifications, I think that we should actually start working on php-http/message:

1. Promise is not message related. The plan is to replace it with a PSR (when it comes to reality). Although promise implementations from client-tools might be moved to the promise repository.
2. I think message factory is something that we probably want to keep separated. It should be used together with psr/http-message, so that you can provide factories with your implementation. I wasn't thinking so far that message factories should be standardized, but the more I am thinking about the more I think they should be. The fact that we have these message factories not next to the messages themselves makes me itchy.

Honestly, we really have many components which can be categorized from this point of view (used with messages) and I haven't thought about them before. Good idea @jeromegamez

[xabbuh]

I would to always use singular instead of plural (so Plugin and Adapter instead of Plugins and Adapters).Utils is the only namespace I would keep in plural.