Ticket #11065 (closed PLIP: fixed)
Ship with plone.app.caching
Reported by: | optilude | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 4.1 |
Component: | General | Version: | |
Keywords: | Cc: | plip-advisories@… |
Description
Motivation
Every serious Plone deployment requires caching to perform. Configuration of a caching reverse proxy is not enough: Plone needs to add the correct response headers.
plone.app.caching is a new effort to simplify and sanitise the setting of caching response headers.
It learns from CacheFu (and has feature parity with it), but is much simpler. It uses z3c.caching to let developers declare how their views should be cached, rather than relying on configuration of a third party system. It has good documentation and sensible default policies for standard Plone content types and resources. It needs no monkey patches, and does not use Archetypes as a storage model.
plone.app.caching is in production use in at least two Plone 4 early adopters.
Assumptions
- PLIP #9472 (include plone.app.registry) is included, since plone.app.caching depends on this
Proposal & Implementation
- Add plone.transformchain, z3c.caching, plone.caching, plone.cachepurging and plone.app.caching to the Plone 4.1 KGS
We could then either:
- add plone.app.caching to the installers' buildout.cfg eggs list
- or, add plone.app.caching as a dependency of the Plone egg
(it will auto-configure via z3c.autoinclude)
Deliverables
See above
Risks
We've been here before with CacheFu, which was added to Plone 2.5, and then lagged behind 3.0. The authors and maintainers of plone.app.caching (principally myself and Ricardo Newbery) hope that it'll be easier to keep up the commitment this time around due a simpler, saner architecture and a lack of crazy monkey patches.
Participants
Martin Aspeli Ricardo Newbery
Progress
plone.app.caching is used in production. A KGS can be found at http://good-py.appspot.com/release/plone.app.caching/1.0b1
Change History
comment:5 follow-up: ↓ 6 Changed 5 years ago by rossp
(In [46194]) Add some FWT discussion notes. Refs #11065.
In discussion with the FWT, we have some suggestions regarding the installation/activation/enabling story. If an admin activates the add-on, that seems a pretty clear indication that they want caching, so maybe "enable caching" should be on by default. Also, though it's covered in the documentation, it's not very clear from the control panel UI that one needs to do more than just check "enable caching" to get caching. So it would be good to have something on that view that points the user to the "import settings" tab. Another suggestion that would be great to see would be to display a portal status message when "enable caching" is checked but no caching profile has been imported, like we do with the mail host settings. These two changes may reduce some confusion for new users.
comment:6 in reply to: ↑ 5 ; follow-up: ↓ 7 Changed 5 years ago by rossp
Replying to rossp:
Copying an email response from optilude:
I'm +1 on status message and more text, but -1 on automatically enabling. I think we may want to ship with it installed in Plone, but disabled, rather than uninstalled. And if people install it as an add-on, I think they still need to make some conscious choices about their caching policy, or their site could be screwed up. We can't really detect whether you have Squid/Varnish in front, for example, which makes a difference in terms of what a "sensible default" should be.
comment:7 in reply to: ↑ 6 Changed 5 years ago by rossp
Replying to rossp:
Copying an email response from optilude:
I'm +1 on status message and more text, but -1 on automatically enabling. I think we may want to ship with it installed in Plone, but disabled, rather than uninstalled. And if people install it as an add-on, I think they still need to make some conscious choices about their caching policy, or their site could be screwed up. We can't really detect whether you have Squid/Varnish in front, for example, which makes a difference in terms of what a "sensible default" should be.
Will someone work on the status message and better descriptive text for this? I really want to see at least that done before merging. Everyone on the FWT wants to see this merged so we wouldn't make this a blocker, but just a small amount of time to add some end-user hand holding would go a long way. Can someone work on this?
comment:10 Changed 5 years ago by esteele
- Status changed from new to closed
- Resolution set to fixed
(In [39693]) Buildout for plone.app.caching integrations. Refs #11065