Note to self: do this!

I wasn't expecting a comment, but thanks for the heads up :)

I had seen cachetags just recently, but it's currently out of question because for me because it requires a core patch. Also, my planned approach on the problem is a bit less abstract, but has a wide variety directly useable features beyong the cache layers. It is very tightly bound to Varnish vcl (which I happen to be quite familiar with).

Efficient cache clearing is just one part, there are many other useful things related to varnish and content tagging. For example I could decide which entities to tag during what conditions, if at all. I could also do totally different tagging, such as: "this page is to cached per user", or tell varnish to "do esi-rendering on this page", or "make sure this page is invalidated before x" (while having a different cache_control) etc. By using context & rules + a custom admin UI, the configuration is easy/intuitive and still very site specific. The UI should auto-generate VCL code based on the current configuration. That's my plan at least.

I didn't know about the D8 core issue though, that was quite an interesting read. I commented on the issue. That approach has great potential, hoping to see it soon for D7 . I kind of felt a "damn, it's been done already", but after reading through I'd say my approach is different enough, and mostly addressing other issues :)

If it turns out that I'm duplicating module efforts, I won't even try publish this module. Or I will try to merge it with another module.

@kristofvanroy
Thanks for the interest. I took a shot of your steroids.

It seems to do lots of stuff while putting everything in one module. It seems neat and functional, but to be honest I much prefer reusing common modules. expire and max_age can be incorporated easily as they're minimal. Still, activating them separately will IMO create no noticiable overhead. I would rather keep varnish connection in the varnish-module, and just reuse the connection. Then all varnish adminconnection related stuff can be developed in a common and logical place.

I'll admit, my module would also cover functionality from expire and max_age, but only by re-using the flexibility of context and rules, so that would be just a minor configuration.

Rules & context are what I definitely will to base the functionality on (for maximum flexibility). Steroids seems to be going in another direction currently. I cannot also base my current customer project on steroids. I'm trying to do it the healthy way, even with some great challenges :)

When I put some code available you might be able to use it in your project (with my help or not), but your approach is likely too different. That is unless you plan to integrate heavily into context & rules.