HTTP Cache Bundle

[ddeboer]

This is a proposal for a bundle that combines setting caching headers (filling the cache) and invalidating (purging) cache entries. As a basis, we (David Buchmann from Liip and David de Boer from Driebit) want to merge the LiipCacheControlBundle and DriebitHttpCacheBundle. The two of us would also volunteer as initial maintainers for the bundle.

Setting HTTP caching headers

Currently,

• one can set caching headers manually on the Symfony Response object
• use the SensioFrameworkExtraBundle to set caching headers in annotations.

This bundle adds an option to configure caching headers from your config.yml (ported from LiipCacheControlBundle).

Invalidating HTTP cache entries

The bundle includes a generic approach to invalidating cache entries (ported from DriebitHttpCacheBundle and including some parts from the Liip bundle).

How to proceed

1. Get input on any other bundles or libraries (including non-PHP ones for inspiration) that we should consider.
2. Opinions on whether this could be accepted by the FOS community.
3. We'll create a separate repository that can be used for discussing the bundle's implementation details and prepare the bundle for moving it to FOS once it's ready.

[dbu]

we started the repository where we merge things over here https://github.com/ddeboer/FOSHttpCacheBundle

[lsmith77]

the structure of FOS has of course diverged since our original plans of where everbody worked on all the Bundles to one or two people at best working on one Bundle. however FOS is maybe now a good place for merging Bundles where the previous Bundles have served as a proof of concept for both the implementation as well as showing that there is a demand for it. Also the special role that FOS plays in the community can help focus community resources. so I generally support this proposal.

[willdurand]

:+1: on that, but as I told you during the hackday, the bundle should be "stable" before moving to the FOS organization, and you should be able to support/maintain it.

[fabpot]

:+1:

[ddeboer]

We split off the code which is not Symfony-specific into a separate library: https://github.com/ddeboer/FOSHttpCache. This library will be ready for 1.0 in a couple of days. How should we go about moving it to the FOS namespace? Should I just transfer the repo to FOS and wait for you guys to accept it?

After the library's been published, we'll continue working on a 1.0 release for the bundle.

[dbu]

@ddeboer i suggest to do a 1.0.0-alpha once the library is moved to FOS and registered with packagist, and wait with a stable tag until the bundle is finalized too. but the time for moving it over here seems right to me

[ddeboer]

@dbu Makes sense, and it gives us the opportunity to process any feedback on both library and bundle before 1.0 final.

[ddeboer]

Tagged the lib 1.0.0-alpha1. I wasn’t able to transfer the repo to FOS because I don’t have admin rights there. How should we move the library to FOS?

[stof]

@ddeboer Will you be the maintainer of the repo ?

[ddeboer]

@dbu and me, yes.

[stof]

OK, then I'm adding you to the organization (our rule currently is that all members are owners)

[ddeboer]

Thanks!

[stof]

You might need to disable scrutinizer and travis first before moving the repo, and to re-enable them after the move though (and packagist could also require a manual intervention from @Seldaek )

[ddeboer]

The repo wasn’t on Packagist yet, so that shouldn’t be a problem. Re-enabled Travis and Scrutinizer.

Thanks for the help, @stof!

[mvrhov]

ANY ETA on when will the bundle be moved here? So I can actually install it from the packagist

[dbu]

hi @mvrhov thanks for the ping. we still have some heavy refactoring on the configuration to do after the union of the predecessor bundles. if you start using it now you need to expect quite some moving around. that said, you can add something along these lines in your composer.json to already get the bundle: https://getcomposer.org/doc/05-repositories.md#vcs

i am quite hooked up in the symfony cmf release these days, but i really hope we get that out next week. then i can focus on the cache bundle and finally wrap things up. i would hope to get something out this month still, but don't hold your breath ;-)

[mvrhov]

@dbu: I figured out before you answered on how to add it into the composer.json. I don't mind changing the configuration as I'm running most of the packages on the bleeding edge for this project so let's say that I'm quite used to it. Thanks for approximate ETA.

[stof]

@dbu @ddeboer when do you expect the bundle to be ready enough to be moved to the organization as well ?

[ddeboer]

@stof My focus is on getting the library to 1.0 stable; that shouldn’t be too long. After that, there are some PRs on the bundle that I want to have merged first.

@dbu What about tagging an alpha and moving the bundle to FOS by this weekend?

[lsmith77]

+1 .. lets not try to get perfection before we do the move. i am sure with the move the bundle will gain more visibility and potentially a few more good contributions and eyes reviewing.

[stof]

@ddeboer I prefer keeping the library in beta mode until we have at least a beta of the bundle as well. This would avoid issues if we find that the bundle requires a library change to finish it. Ideally, they should enter the RC phase at the same time.

@lsmith77 totally right: I haven't reviewed the bundle fully for instance.

[ddeboer]

@stof Makes sense.

[dbu]

:+1: for moving end of this week.

i hope to wrap up the open PRs on the bundle. when that is done, lets move and tag alpha1.

[ddeboer]

Moved the bundle to FOS, tagged alpha1 and added to Packagist, so @mvrhov and others, you can now install it from there.

[mvrhov]

thanks

[stof]

Closing as both repos have now been moved