cleanup service configuration files and move unit tests into Unit namespace

[dbu]

This will break every pull request touching tests or the DI configuration...

But i think we need to clean up the naming. This is already a start, but there might be more.

[dbu]

is there a particular reason the LogSubscriber has "proxy" in its service name? the pattern would be fos_http_cache.event_listener.log

[ddeboer]

That’s better, yes.

[ddeboer]

Yep, the names are a mess. 😉

We should also standardize whether we user EventListeners or EventSubscribers (we now have both). EventSubscribers are easier to configure, but are tied closer to Symfony because they have to implement EventSubscriberInterface. Which do you prefer?

[ddeboer]

And what about the Varnish and Nginx classes in the library and their config params in the bundle? They are now in the library’s Invalidation namespace (we may have already talked about this before).

• Is that namespace appropriate? They implement CacheProxyInterface. Would ProxyClient or CacheProxyClient or CachingProxyClient be better?
• What should the config param in the bundle be? proxy_client? Or should we just put it in the root level?

[dbu]

indeed, i wondered why we call them CacheProxy even though they are not a proxy but a client to the proxy. lets call them ProxyClient - that the proxy is about caching should be clear from the library name already.

for using in the bundle, i think it makes sense to have a proxy_client.varnish and other proxy_client.X and then define the alias from the DI class for default_proxy_client. that way some really complicated setup could even run both varnish and nginx or symfony built-in cache clients, and add his own services with the other clients.

event listener versus subscribers: i dont know, lets go for subscribers, they are more readable imo.

ps: something looks weird with the testing. it says "All is well - Scrutinizer timed out" and does not mention travis at all.

[dbu]

okay, updated the file name and the proxy => event_listener.

i suggest we do the renaming to ProxyClient and the transformation to event subscribers in separate PR - those are less prone to merge conflicts.

[ddeboer]

why we call them CacheProxy even though they are not a proxy but a client to the proxy

I have no idea. 😄

Do you also want to support multiple cache managers?

Should we change the namespace from Invalidation to ProxyClient in the library, too?

[dbu]

okay, i merged and created 2 new issues from the discussion.

i would not provide multiple cache managers at this time. lets see what people come up with as requirements and ideas how this could be done.