Refactor User Context HttpCache handling into its own class

[dbu]

We provide a HttpCache class extending the symfony kernel to handle user context requests.

We should move all business logic into a separate class and have minimal impact on the actual kernel class. People could still use our kernel, or they could copy the few lines just like you copy varnish configuration.

@lolautruche wdyt?

[lolautruche]

Not sure it worths it honestly. Impact is already minimal (see handle()). And it will be almost impossible for future improvement such as tag based invalidation.

[dbu]

its still > 100 lines of code, for something that could be like 5 lines in the kernel. i think i will try a PR.

why do you think the tag based invalidation can not be encapsulated? in the end, we should have a class that is called from a few of the kernel methods to do its stuff. banning on headers needs a meta index, but i think even that could be completely encapsulated in that separate class (its only a meta-index to find cached content by header, right?)

[lolautruche]

why do you think the tag based invalidation can not be encapsulated?

Actually it will be part of the extended store. A few lines will have to be added to the HttpCache class to use the Store and deal with invalidation.

[ddeboer]

@dbu Please create that PR: I’d prefer composition over (HttpKernel) inheritance.

[dbu]

i created #177 now - indeed the kernel part becomes a lot more lean. but we end up with another layer of event handling, it looks like :-/

[stof]

Would it make sense to extract this code outside the bundle, to make it reusable for other people wanting to use the HttpCache (Silex, StackPHP, ...) ? The bundle could then depend on this library as well.

[stof]

Extracting it out of the bundle would even make more sense once we implement #168 and #167 as the number of extra HttpCache features will become bigger.