Skip to content

Conversation

andrerom
Copy link
Contributor

@andrerom andrerom commented Aug 9, 2015

Aims to allow support for tagging also on Symfony HTTP Cache and
potentially other caches by limiting the feature to focus on only
tags and not random headers.

Closes #234

  • explain changes in CHANGELOG.md
  • Update documentation

README.md Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i suggest:

... and Symfony HttpCache.

@dbu
Copy link
Contributor

dbu commented Aug 10, 2015

@ddeboer can you please also give your input here? there are some architectural decisions to take, would appreciate your opinion.

@andrerom
Copy link
Contributor Author

Did an attempt to move tag header name, value, and escaping down to cache invalidations. Looks a bit better imo.

README.md Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think we wrote HttpCache elsewhere (the php class is written in camelcase)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct.

@dbu
Copy link
Contributor

dbu commented Aug 15, 2015

at this point, the only thing the TagHandler is doing is collecting the tags for tagging a response. that is really not much. i think we should either let TagHandler talk to the proxy client directly or get rid of the handler and move all to CacheInvalidator. i tend to keep TagHandler because its a whole topic of its own and not only about invalidation. I wonder if the TagInterface should be outside the Invalidation namespace, because it is not only about invalidating tags but also about tagging responses.

@dbu dbu added this to the 2.0 milestone Aug 15, 2015
@andrerom
Copy link
Contributor Author

I wonder if the TagInterface should be outside the Invalidation namespace, because it is not only about invalidating tags but also about tagging responses.

ok, so then I'll skip the header related parts added to CacheInvalidator as well right? (given we then instead inject the tag "something in lack of calling it invalidator anymore" instance)

@dbu
Copy link
Contributor

dbu commented Aug 17, 2015 via email

@andrerom
Copy link
Contributor Author

ok, no problem. Probably vacation :)

@ddeboer
Copy link
Member

ddeboer commented Aug 17, 2015

That's right, I'm on holidays. Back in civilisation with proper internet connection in a week. :)

@dbu
Copy link
Contributor

dbu commented Aug 18, 2015

@andrerom sorry to keep you waiting, but i would prefer to wait for the other david to be back before we take a decision on how to do this one. its a rather important architectural decision.

@andrerom
Copy link
Contributor Author

No problem, opened a possible followup issue to discuss in the mean time (#241).

@andrerom
Copy link
Contributor Author

@ddeboer any views on this topic?

@ilukac
Copy link

ilukac commented Sep 15, 2015

This looks promising. With this feature we could better optimise invalidation...

@andrerom andrerom mentioned this pull request Sep 30, 2015
2 tasks
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not private?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this, and maybe some other parts will be needed for HttpCache as well

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

@ddeboer
Copy link
Member

ddeboer commented Sep 30, 2015

Very interesting! I agree with the general approach: we’ve been following Varnish terminology in differentiating purge, refresh and ban, but nothing is stopping is from introducing a separate tags type.

Did an attempt to move tag header name, value, and escaping down to cache invalidations. Looks a bit better imo.

@andrerom Can you elaborate a bit on why you did this? Especially since @dbu and I decided earlier to move tag-specific logic out of the CacheInvalidator and into the TagHandler.

@andrerom
Copy link
Contributor Author

@andrerom Can you elaborate a bit on why you did this? Especially since @dbu and I decided earlier to move tag-specific logic out of the CacheInvalidator and into the TagHandler

I'll need to read up on the discussions above where @dbu and me hit some issues with first approach, but think it was among other things because some of the escaping was clearly varnish specific.

@ddeboer
Copy link
Member

ddeboer commented Oct 1, 2015

Right, in the discussion (on outdated diffs) I read:

i think we should move this out of here and the CacheInvalidator. if a header is needed, its up to the client to know that, its an implementation detail specific to the caching proxy.

@dbu Did you mean here to move the tag header logic into CacheInvalidator? If we’re saying it’s client-specific, it should go into the proxy client classes (Varnish/Nginx/Symfony/AbstractProxyClient). After all, we use a header for tagging in Varnish, but we won’t be using one in Symfony HttpCache (if I understand #234 correctly).

In the current solution, getTagsHeaderValue (e.g.) is duplicated in CacheInvalidator and TagHandler.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/service/helper/ ?

@andrerom
Copy link
Contributor Author

@dbu second pass

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think the first line can simply be removed, it does not say anything more than the second line.

@dbu
Copy link
Contributor

dbu commented Nov 18, 2015

cool! can you adress these last two details and squash commits? then we can merge this.

@andrerom
Copy link
Contributor Author

done

Aims to allow support for tagging also on Symfomy HTTP Cache and
potentially other caches by limiting the feature to focus on only
tags and not any random header.

Closes FriendsOfSymfony#234
@andrerom
Copy link
Contributor Author

~~Still failing on doc, as I don't know anything about rst, how is it supposed to work?~~~

fixed in bc36103

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you have a - too much. the line should start with ..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, copy past fail, hopefully fixed in bc36103

dbu added a commit that referenced this pull request Nov 18, 2015
Add abstracted tag handling
@dbu dbu merged commit 5a3d88a into FriendsOfSymfony:master Nov 18, 2015
@dbu
Copy link
Contributor

dbu commented Nov 18, 2015

great job, thanks a lot for your patience!

@andrerom
Copy link
Contributor Author

@dbu Likewise :)

@ddeboer
Copy link
Member

ddeboer commented Nov 18, 2015

Thanks @andrerom and @dbu! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants