Changing namespace to Http\Plugin

[joelwurtz]

Would like to change the namespace to Http\Plugin before releasing a version of plugins, WDYT ?

[dbu]

once we release, we can't change the namespace anymore, its one of the most massive BC breaks we could do :-) so yes, lets clean it up now. namespace would become Http\Plugins with an s at the end, right?

[sagikazarmark]

For the sake of completeness: there is a way to workaround renaming classes: aliasing. I think it is an acceptable solution.

Agree with the rest. 😝

[jeromegamez]

I'm hesitant about dropping the Client sub-namespace - if all plugins are to be used in a HTTP Client, I think it would be good to keep it. If the plugins can also be used in a future "HTTP Server" implementation, dropping the namespace would be okay, but the Client-only plugins should be sub-namespaced separately.

E.g. the HttpAuthentication plugin certainly is relevant to Clients only, the Logger Plugin could certainly be used outside of a client.

[sagikazarmark]

This seems to be a valid argument as well. Wonder if that's true for other packages (utils, tools) as well.

[joelwurtz]

Does something like Http\ClientPlugins would do then ? My main concern is to really separate from the Http\Client to not overlap

[joelwurtz]

@jeromegamez look at php-http/httplug#98 for the reasoning behind this change.

[sagikazarmark]

Well, I don't have any plans related to server stuff, but we are not limited to HttpClient, so who knows. I would say Http\Plugins is good enough for now. If we ever really need separation between Server and Client plugins we can create subnamespaces like Http\Plugins\Client/Server. We can even do this with a deprecated fallback to the original namespace, so that we are not forced to do a major version upgrade.

WDYT?

[jeromegamez]

I think, renaming the repo to "client-plugins" would be the simplest - everything inside this repo is below the Http\Client\Plugin namespace, so there's no possibility to overlap with something from a higher namespace.

If one day, we were to provide more general plugins that could be used in contexts other than "Client", we could still refactor that.

[sagikazarmark]

I have a suspision that @joelwurtz wants to move things out of the Client namespace to be one step closer to the "master repo" idea. With unrelated stuff in that namespace/directory makes it a bit harder.

(Apart from making things clear of course 😄)

Am I right? 😉

[joelwurtz]

Yes @sagikazarmark :), would allow to do that better.

But this is also for consistency between all packages. I understand this one is tricky, but want to do this step by step.

[jeromegamez]

Ah, the perils of decoupling, I didn't notice php-http/httplug#98 :) - you all already have discussed this in more detail, so I wouldn't want to interfere too much, at least not here 😄 -> I will comment in the other thread :)

[sagikazarmark]

Yes @sagikazarmark :), would allow to do that better.

I had a million dollar bet on it. 😛