Merge client tools and utils

[sagikazarmark]

Based on #98 I have the idea to merge the two packages mentioned in the title.

Current content of the repos:

• Utils:
  • BatchClient (and related stuff)
  • MethodsClient
  • Message factories (moving to php-http/message)
• Client Tools
  • Client decorators and emulators
  • Promise implementations (moving to php-http/promise)

Content after restructuring code:

• Utils:
  • BatchClient (and related stuff)
  • MethodsClient
• Client Tools
  • Client decorators and emulators

I thing these things could be merged into one package, because they are all client related stuff, even if they can be implementor/user stuff.

Something like client-extra, client-common. I think utils and tools are not really reflecting the reorganized structure.

[joelwurtz]

+1 for a php-http/common repository, regrouping all implementation things that are too small, without dependancies, and which does not make sense to be alone.

[sagikazarmark]

Although initially this idea was about to collect only client related stuff here, but I see no reason why other stuff could not be moved here.

[dbu]

hm, we are shuffling things around a lot, and while we still can do, we should not do it too often again :-) but i agree, was confused by utils vs tools as well.

-1 for php-http/message: its confusing that the contract is in php-http/message-factory, and some implementations are in php-http/message.

do i assume correctly that the reasoning to not put the factories into utils is the dependency on the message-factory package? i fear that makes sense, but lets call that repository message-factory-implementations. longer but much clearer.

for the rest, we would keep utils and rename client tools to client-common and client-extra?

[sagikazarmark]

we should not do it too often again

Agreed. 😄

-1 for php-http/message: its confusing that the contract is in php-http/message-factory, and some implementations are in php-http/message.

That's only true, because those factories are not shipped with their message implementation and they should be.

do i assume correctly that the reasoning to not put the factories into utils is the dependency on the message-factory package

Nope, the reason why I started some sort of reorganization is to lower the number of packages. The message repo contains various kinds of message related stuff, not just message factory. It's more like message-common.

for the rest, we would keep utils and rename client tools to client-common and client-extra?

Utils and tools are both evil from a naming point of view. My biggest concern became that a user might not know which serves what purpose. "Wow, to packages with a name meaning nothing? Close the browser!"

[sagikazarmark]

@dbu take a look at these PRs: https://github.com/php-http/message/pulls

[dbu]

ah, i see. i think that makes a lot of sense!

[sagikazarmark]

ah, i see. i think that makes a lot of sense!

What does? 😄

[dbu]

the message consolidation into one repository makes sense :-)

with the client implementor helper code and the httplug user helper code: i guess the big stumbling point is optional dependencies. can you please summarize again what the proposal for the two repos is now?

[sagikazarmark]

Well, I am thinking about putting them into the same repos. Or at least, BatchClient and HttpMethodsClient should be moved to client-common or common-client which is a better name IMO than utils. With this message/client categorization we don't need utils (for now).

About client-tools: I am not so sure now it is a good idea to pack that stuff together with client common. Currently only convenience traits are in client-tools.

So utils should definitely be common-client instead. Client-tools? Not sure yet. Maybe we could merge them together, maybe not.

[sagikazarmark]

Actually it could also just be called client, couldn't it? Or is it a major collision with httplug?

[dbu]

i think php-http/client would be confusing, it sounds like the main thing. client-utils? while utils on its own is not very telling, it indicates that this is just additional stuff that could be useful, not a core piece of the architecture. the tools repo could be php-http/implementor-tools

[sagikazarmark]

i think php-http/client would be confusing

yeah, was just an idea

client-utils

Sounds better, but I still it still doesn't tell you that "This repository contains some client implementations which you might find useful, such as batch client, http methods client, etc).

[sagikazarmark]

Actually: we might even move pluginclient there. Plugins could be a collection of plugins? So you can install plugin client without installing a bunch of default plugins?

[dbu]

imo the plugin client is fine in the plugin repo. you can't really use
one without the other. i think chances that a real setup does not want
at least some of those plugins are very small.

oh but the names. i really don't know. priority for me is:

1. let this be the last time we need to change them
2. have something self-explanatory that also fits in the future if we
   add more stuff.