[WIP] Add Varnishadm CLI client

[ddeboer]

Fix #61.

1. The idea is that using this client involves less custom VCL. However, for the ban lurker to work, some custom VCL is still necessary to copy e.g. the URL header to X-Url.
2. As far as I know, purge cannot be done through varnishadm, so we should either not implement PurgeInterface or fake the purge by actually doing a ban when purge() is called.
3. Same goes for refresh. We could fake it by doing a ban and then manually getting a fresh response from the application.

[dbu]

very cool! my main question at this point is whether we could move the code dealing with sockets and sprintf-ing commands into a VarnishCli class to better separate the concerns.

[ddeboer]

We can add a VarnishCli class, and it will help in separating concerns a bit, but I don’t think we’ll be communicating with any other Varnish command line tools.

Do you mean a VarnishAdmin that wraps multiple VarnishClis for talking to multiple servers?

[dbu]

Do you mean a |VarnishAdmin| that wraps multiple |VarnishCli|s for talking to multiple servers?

yes. having a VarnishCli would clearly separate what is the logic to talk to cli and what is our domain logic of the caching proxy client. the proxy client would handle several cli instances to multiplex to each varnish.

[dbu]

rebased to get rid of the outdated php-http reference

[dbu]

@ddeboer any chance you could wrap this up for 2.0?

[ddeboer]

As this is no priority for myself now, I suggest to remove this from the 2.0 milestone so we can move forward on 2.0. I we can add this functionality on the 2.0 branch later on, that’s fine. If we need to break BC it can wait until 3.0 (for me).

[dbu]

pitty, but i removed the milestone