Extract plugin interface and logger/cache plugins

[sagikazarmark]

As mentioned in #61

[Nyholm]

I think this is a good idea. But we should be careful not to over engineer our package design. The more packages you have the more maintenance you will get.

At the moment there is quite a few issues (#56, #57, #58, #59) that will add complexity to the cache plugin. So it might be worth considering moving the cache plugin to a different package.

[sagikazarmark]

Our current setup makes it quite hard to create separate/custom plugins without tons of dependencies.

So what we should/could do:

• Extract the plugin interface: since it is an interface package, it does not require too much maintenance
• Extract the plugin client: it allows to use any plugins without ours
• Have the current plugin collection as is with plugin and plugin-client as dependencies to preserve BC

Optionally: extract any plugins with external dependencies. This one is a bit harder, as we either cannot make hard dependencies in the already existing plugins, or they will kind of conflict with the current plugins package.

[dbu]

i share the concern of tobias, the complexity. why would we need the plugin interface and the plugin client separate? and does it hurt having trivial plugins distributed along with that? maybe we should rather move more complex plugins into separate repositories. cache would be the most likely candidate for that. its also less universally needed than the basic header things and retry and similar.

[joelwurtz]

👎 on this, we currently have too many packages IMO and don't want to separate this even more.

I'm more on moving complex plugins into their own repository like @dbu said on the cache one.

On the contrary i would be more in favor on merging the plugin package with the common-client package, (for me PluginClient is a common client)

So that in fact we have the following packages :

• HTTPlug : interfaces for sending requests
• Message : Implementation, tools and other things about PSR7
• CommonClient (or another name) : Implementation, tools and other things about HTTPlug interface
• A package for each client / adapters

[sagikazarmark]

Moving the PluginClient to client-common sounds an interesting idea.

How would the dependency look like in that case:

• Require the plugins package in client-common?
• Require client-common in plugins (which is the case actually right now)?
• Second option+moving the plugin interface as well?

Keeping PluginClient and Plugin interface together is a good idea, I just wrote it for the sake of completeness.

Another upside of this idea: Creating separate plugin packages becomes a little bit cleaner this way IMO. The plugin implementations require a few dependencies, while client-common only require two small ones.

So my vote goes two option three from the list above.

[sagikazarmark]

See php-http/client-common#14 and #64

[dbu]

i can agree with the 2 pull requests. i am not sure if we gain anything by it, but it is also not worse.

we need to keep the doc in sync here as well, e.g. the description of what the plugin repo provides.