Let CMFPlone depend on plone.app.caching

[thet]

Currently plone.app.caching is only a dependency of the Plone distribution package (see: https://github.com/plone/Plone/blob/master/setup.py#L38 ). Not having plone.app.caching available doesn't even make use of ram caches and makes the site really slow.

I propose to add this dependency directly to CMFPlone.

/cc @plone/framework-team

[mauritsvanrees]

For a site that is only internally available, or where everyone is always authenticated, plone.app.caching may not give you much improvement, unless you spend a long time configuring it. I would always add it myself (same for plone.app.upgrade btw), but if we can keep it out of the dependencies, I think that would be nice.

[thet]

I saw response times of 20sec for each request vs 50ms for a site because apparently the Zope RAM cache wasn't leveraged without plone.app.caching installed. I think plone.app.caching makes sense also for internal sites unless something else was wrong. I also explicitly depend on plone.app.upgrade, e.g. for a separate service instance.

[jensens]

I agree with @thet. I always enabled caching even for Intranet sites. The RAM cache is one good reason, but also caching of CSS/JS in browser wont happen in those cases, w/o having sane rules caching delivered. W/o p.a.caching, on every request all JS/CSS and even fonts and icons are delivered.

plone.app.upgrade is a different case. I tend to have an separate service instance with ZMI access for those tasks.

[hvelarde]

probably is also time to review the default caching rules includes in plone.app.caching.

[tomgross]

I agree including p.a.caching is useful for almost 100% of real world usecases. Still I have mixed feelings of including it at as a hard dependency.

• If there is no direct import this is a policy thing. Pip and/or zc.buildout are made for this purpose. One might have another (better?) caching solution.
• Unittesting in Plone is more complex than it should be. Adding more dependencies does not ease this fact.

[jensens]

yes, the caching rules need a review. and yes, from a testing pov it is a good thing to have it separate. and most people use Plone as dependency i suppose.

but the killer argument against including it: more circular dependencies. https://github.com/plone/plone.app.caching/blob/master/plone/app/caching/browser/configure.zcml#L8 (those are not declared in setup.py)

[jensens]

architecture wise now it is an core-addon and thats good.