Out of band tag handling

[dbu]

the current tag handling is all about sending tags with the response and sending tag specific requests to the caching proxy. there is another concept for tagging: storing tag => urls ourselves (database, sqlite, redis, whatever) and send normal refresh / ban requests on invalidation. (see also the symfony con talk by @magnusnordlander)

how can we model this set up? should we add an isInline check to TagsInterface and a saveTags($requestUrl) in ResponseTagger? maybe rather have an InlineTagsInterface for the get header name and get header value methods?
or should we try to hide this away and magically save tags in ResponseTagger on getTagsHeaderValue?

the TagsInterface::invalidateTags looks fine to me. but the clients (Varnish/Nginx/Symfony) should maybe use composition for the functionality rather than implement the method inline, so you can plug either one that calls ban() on the client or the one that calls purge / refresh based on its stored tag to url map.

[ddeboer]

Ping @dantleech, who has already been thinking about (and drawing) this.

[dantleech]

#253 adds a tag ManagerInterface (extending a (tag) InvalidatorInterface) which takes care of invalidating and associating tags with "cache IDs" (could be URL or content digest, or whatever). It also introduces StorageInterface which exists to actually persist these associations (currently a DoctrineCache implementation) - the StorageInterface would be used by ManagerInterface implementations as required.

The tag invalidator (InvalidatorInterface - which is extended by ManagerInterface) is currently passed to the proxy client as an option.

I think that the finished PR should provide the architecture for invalidating, but might still need some jiggling about.

[dbu]

there are two parts here: the library internal architecture how to implement things in a flexible way. the other part is what/how to expose this to the users of the library to make things not overly complicated.

[magnusnordlander]

If you guys want we can set up a Hangout and I can talk a little bit more about how we've implemented our tag manager.

[dbu]

hi magnus, thanks for the offer. that would be cool! i could make time next week tuesday to friday during working hours (GMT +1 timezone, i think norway is in the same zone)

[dantleech]

Anytime would be OK with me.

[magnusnordlander]

Shall we say Tuesday the 15th, at 14:00 GMT+1? (Also, I'm Swedish, not Norwegian :) )

[ddeboer]

Sounds good to me.

[dbu]

works for me. though i have the next meeting at 14:30 so we have a strict timebox. 13:30 would also be possible for me, if we want a bit more time. and sorry for the nationality blunder ;-)

my google identity is david@liip.ch . i can try to assemble people on tuesday. i have @ddeboer but i think i don't have @dantleech in google yet.

[dantleech]

I have never used google hangouts, but my identity would be dan.t.leech@gmail.com, will try and do that.

[dbu]

turns out my meeting was moved, so 14:00 is perfect and i have more time if needed (but lets try to keep this short). i created a gist with an idea how the new interface could look https://gist.github.com/dbu/5b162a6707d8922014c9

[dbu]

okay, i am trying to call you guys on hangout.

[magnusnordlander]

Hangout is up at https://hangouts.google.com/hangouts/_/nordlander.se/cachetags

[dbu]

ah :-)

[dantleech]

Thanks for the chat. What I took away from this is that we should be transactional when handling the tags, otherwise I think we are broadly on the same track with #253

@magnusnordlander is your code available publically?