Ticket #11065 (closed PLIP: fixed)

Opened 6 years ago

Last modified 5 years ago

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:1 Changed 6 years ago by optilude

(In [39693]) Buildout for plone.app.caching integrations. Refs #11065

comment:2 Changed 6 years ago by cah190

  • Cc plip-advisories@… added

comment:3 Changed 5 years ago by rossp

(In [46191]) Add a PLIP review. Refs #11065.

comment:4 Changed 5 years ago by rossp

Reviewed: easy +1 for merging

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:

(In [46194]) Add some FWT discussion notes. Refs #11065.

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:8 Changed 5 years ago by esteele

(In [47002]) Merge branch optilude-plone.registry-fieldref. Refs #11065.

comment:9 Changed 5 years ago by esteele

(In [47003]) Merge branch optilude-plone.registry-fieldref. Refs #11065.

comment:10 Changed 5 years ago by esteele

  • Status changed from new to closed
  • Resolution set to fixed

(In [47004]) New tests and version pins for PLIP #11065. Closes #11065.

comment:11 Changed 4 years ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.