plone.app.caching - portal type config

classic Classic list List threaded Threaded
12 messages Options
Hanno Schlichting-4 Hanno Schlichting-4
Reply | Threaded
Open this post in threaded view
|

plone.app.caching - portal type config

Hi.

I've tried out plone.app.caching and I'm impressed with it! Much nicer
and better than CacheFu :)

One question, though: Do we really need to configure all those
portal_types by default?

What prevents us from looking at some interfaces and determining
folderish and non-folderish content types? Most people don't write new
file or image types, so these are pretty easy.

After importing one of the shipped profiles, these kinds of
associations were the only thing I needed to make - and they felt
rather stupid to me :)

Hanno

------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Martin Aspeli Martin Aspeli
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config

On 21 May 2010 05:53, Hanno Schlichting <[hidden email]> wrote:
> Hi.
>
> I've tried out plone.app.caching and I'm impressed with it! Much nicer
> and better than CacheFu :)

w00t :-)

> One question, though: Do we really need to configure all those
> portal_types by default?
>
> What prevents us from looking at some interfaces and determining
> folderish and non-folderish content types? Most people don't write new
> file or image types, so these are pretty easy.

Well, plone.caching adapts *published* objects, i.e.
request['PUBLISHED'] to obtain a cache ruleset. This is normally a
view.

Unfortunately, for a PageTemplate in a skin folder,
request['PUBLISHED'] is always the same type of object (a PageTemplate
or FSPageTemplate), so we needed another differentiator. Right now,
that just means special-casing the lookup of ruleset from
PageTemplate, by looking at context.portal_type and/or the page
template name. This was always a bit of a workaround, and lives in a
special-case adapter in plone.app.caching only, not in plone.caching.

An alternative might be to store (in the registry/GUI) a list of
marker interface dotted names, resolve them, and see if self.context
provides an interface. However, that seems a bit brittle to me, not at
least because you can't easily build a vocabulary of applicable marker
interfaces, and it may be harder for people to customise if they don't
have access to the original code for the type.

> After importing one of the shipped profiles, these kinds of
> associations were the only thing I needed to make - and they felt
> rather stupid to me :)

I agree. I think we could fix this by moving all our skin items to views. ;-p

Martin

------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Hanno Schlichting-4 Hanno Schlichting-4
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config

On Fri, May 21, 2010 at 2:40 AM, Martin Aspeli <[hidden email]> wrote:
> An alternative might be to store (in the registry/GUI) a list of
> marker interface dotted names, resolve them, and see if self.context
> provides an interface. However, that seems a bit brittle to me, not at
> least because you can't easily build a vocabulary of applicable marker
> interfaces, and it may be harder for people to customise if they don't
> have access to the original code for the type.

Hhm, why do we need this kind of flexibility at all? Usually the view
for a folderish item will be dependent on its children (at least the
nav tree), and the view for a non-folderish item won't be. This is a
bit screwed up when something is used as the default page for
something else.

Couldn't we just have a hardcoded default interface for the folderish
and non-folderish group and use that if no specific portal_type has
been configured?

As long as we require an explicit configuration per portal_type,
people will get less than optimal caching. If they install p.a.caching
for the first time, they'll likely not check the depth of the
configuration screens and miss some of their add-on types. And even if
they do a first time configuration, they'll later install some new
add-on and forget about the caching config. In both of these
situations, I'd like to get people some default caching, which is
conservative and always correct but better than nothing.

>> After importing one of the shipped profiles, these kinds of
>> associations were the only thing I needed to make - and they felt
>> rather stupid to me :)
>
> I agree. I think we could fix this by moving all our skin items to views. ;-p

That's a long term thing we haven't even done for Plone itself. I'm
looking for something that works for Plone 4.

Hanno

------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Martin Aspeli Martin Aspeli
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config

On 25 May 2010 04:05, Hanno Schlichting <[hidden email]> wrote:

> On Fri, May 21, 2010 at 2:40 AM, Martin Aspeli <[hidden email]> wrote:
>> An alternative might be to store (in the registry/GUI) a list of
>> marker interface dotted names, resolve them, and see if self.context
>> provides an interface. However, that seems a bit brittle to me, not at
>> least because you can't easily build a vocabulary of applicable marker
>> interfaces, and it may be harder for people to customise if they don't
>> have access to the original code for the type.
>
> Hhm, why do we need this kind of flexibility at all? Usually the view
> for a folderish item will be dependent on its children (at least the
> nav tree), and the view for a non-folderish item won't be. This is a
> bit screwed up when something is used as the default page for
> something else.
>
> Couldn't we just have a hardcoded default interface for the folderish
> and non-folderish group and use that if no specific portal_type has
> been configured?

Perhaps. We just need to make sure it's obvious how to configure a
custom policy here.

> As long as we require an explicit configuration per portal_type,
> people will get less than optimal caching. If they install p.a.caching
> for the first time, they'll likely not check the depth of the
> configuration screens and miss some of their add-on types. And even if
> they do a first time configuration, they'll later install some new
> add-on and forget about the caching config. In both of these
> situations, I'd like to get people some default caching, which is
> conservative and always correct but better than nothing.

That is a somewhat broader question, actually, because in this
scenario you probably also want to set some defaults for things using
standard browser views (so far we've talked about the somewhat awkward
FSPageTemplate/PageTemplate fallback). But I agree that sensible
defaults are, well, sensible. ;)

We may need an additional hook in plone.caching that is a more general
fallback point, I'm not 100% sure.

I'm actually more worried about caching views that shouldn't be cached
at all, e.g. the /atct_edit view or whatever, by accident. We'd
probably need to restrict it quite explicitly to views listed in the
FTI, and to perform that check efficiently. Not impossible, of course.

>>> After importing one of the shipped profiles, these kinds of
>>> associations were the only thing I needed to make - and they felt
>>> rather stupid to me :)
>>
>> I agree. I think we could fix this by moving all our skin items to views. ;-p
>
> That's a long term thing we haven't even done for Plone itself. I'm
> looking for something that works for Plone 4.

Of course, I was joking.

Martin

------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Ricardo Newbery-2 Ricardo Newbery-2
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config


On May 24, 2010, at 5:09 PM, Martin Aspeli wrote:

> On 25 May 2010 04:05, Hanno Schlichting <[hidden email]> wrote:
>> On Fri, May 21, 2010 at 2:40 AM, Martin Aspeli <[hidden email]
>> > wrote:
>>> An alternative might be to store (in the registry/GUI) a list of
>>> marker interface dotted names, resolve them, and see if self.context
>>> provides an interface. However, that seems a bit brittle to me,  
>>> not at
>>> least because you can't easily build a vocabulary of applicable  
>>> marker
>>> interfaces, and it may be harder for people to customise if they  
>>> don't
>>> have access to the original code for the type.
>>
>> Hhm, why do we need this kind of flexibility at all? Usually the view
>> for a folderish item will be dependent on its children (at least the
>> nav tree), and the view for a non-folderish item won't be. This is a
>> bit screwed up when something is used as the default page for
>> something else.
>>
>> Couldn't we just have a hardcoded default interface for the folderish
>> and non-folderish group and use that if no specific portal_type has
>> been configured?
>
> Perhaps. We just need to make sure it's obvious how to configure a
> custom policy here.
>
>> As long as we require an explicit configuration per portal_type,
>> people will get less than optimal caching. If they install  
>> p.a.caching
>> for the first time, they'll likely not check the depth of the
>> configuration screens and miss some of their add-on types. And even  
>> if
>> they do a first time configuration, they'll later install some new
>> add-on and forget about the caching config. In both of these
>> situations, I'd like to get people some default caching, which is
>> conservative and always correct but better than nothing.
>
> That is a somewhat broader question, actually, because in this
> scenario you probably also want to set some defaults for things using
> standard browser views (so far we've talked about the somewhat awkward
> FSPageTemplate/PageTemplate fallback). But I agree that sensible
> defaults are, well, sensible. ;)



This is the question isn't it?  What are sensible defaults?  And can  
those defaults be applied generically?

I'm not sure it's practical to apply a generic caching policy to all  
third-party content items.  Most caching policies are engineering  
tradeoffs.  In p.a.caching, the default operation defined for the  
builtin itemViews and folderViews is actually pretty weak.  Anything  
more aggressive generally requires some custom configuration and some  
tradeoffs in cache freshness.  The weak caching operation just forces  
a revalidation request on subsequent requests to check if the etag or  
last-modified value has changed.  I'm not sure we can define a  
sensible default for the revalidation header for all generic third-
party content items.  In fact, I'm not even sure it's sensible to  
assume that it's safe to cache all generic third-party content items  
at all... even just weakly.

Ric



------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Hanno Schlichting-4 Hanno Schlichting-4
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config

On Tue, May 25, 2010 at 10:14 AM, Ricardo Newbery
<[hidden email]> wrote:
> I'm not sure we can define a
> sensible default for the revalidation header for all generic third-
> party content items.  In fact, I'm not even sure it's sensible to
> assume that it's safe to cache all generic third-party content items
> at all... even just weakly.

Ok. In this case, here's what I'd do:

- Include plone.app.caching into Plone Core (maybe a 4.1 PLIP).
- Enable a default simple caching policy for all types.
- Add-ons which cannot be cached according to this policy need to opt-out.

I assume 80 to 90 percent of all content types are standard Archetypes
based types, with very little special logic. It's the typical thing
you write for every customer project. I want to cache those, not the
10% of fancy composite page or whatever special types.

Hanno

------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Martin Aspeli Martin Aspeli
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config

On 29 May 2010 22:13, Hanno Schlichting <[hidden email]> wrote:

> On Tue, May 25, 2010 at 10:14 AM, Ricardo Newbery
> <[hidden email]> wrote:
>> I'm not sure we can define a
>> sensible default for the revalidation header for all generic third-
>> party content items.  In fact, I'm not even sure it's sensible to
>> assume that it's safe to cache all generic third-party content items
>> at all... even just weakly.
>
> Ok. In this case, here's what I'd do:
>
> - Include plone.app.caching into Plone Core (maybe a 4.1 PLIP).
> - Enable a default simple caching policy for all types.
> - Add-ons which cannot be cached according to this policy need to opt-out.
>
> I assume 80 to 90 percent of all content types are standard Archetypes
> based types, with very little special logic. It's the typical thing
> you write for every customer project. I want to cache those, not the
> 10% of fancy composite page or whatever special types.

I think this is sensible, especially if we have an easy way to opt out
through the GUI.

One option would be to register a very general lookup for
(IBrowserView, Interface) and (IPageTemplate, Interface) (i.e.
register one adapter factory twice, or have two variants, but they'd
be quite similar) instead of the PageTemplateLookup that does
something like this:

 - Attempt to look up a ruleset using z3c.caching.registry.lookup()
and return that if found. This is necessary because this adapter would
override the default lookup in most cases

 - Get the name of the published object (i.e. the name of the view or
page template)
 - Find the parent, i.e. a content object

 - If the parent is a content object:
   - Get the default view of the parent
   - If the name of the published object is the same as the default
view of the parent:
     - Look up a ruleset on the parent object (see below) and return
if that matches
     - Otherwise, look up the parent type in the content type mapping
(as PageTemplateLookup does now) and return that if found

 - Look up the published name in the page template mapping (as
PageTemplateLookup does now) and return that if found

The main change here is that in addition to doing a lookup by named
content type when we encounter the default view of an item, we look up
a ruleset based on the type of the context. This would allow us to
register a ruleset for IBaseContent and IBaseFolder, for example.

If we do this, we could potentially hide the content type and template
mappings from the UI or at least make them less prominent. I think
they're useful safety valves, though, not at least because you can use
them to set a "no cache" rule.

Ric, how does this sound?

Martin

------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Ricardo Newbery-2 Ricardo Newbery-2
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config


On May 29, 2010, at 8:43 AM, Martin Aspeli wrote:

> On 29 May 2010 22:13, Hanno Schlichting <[hidden email]> wrote:
>> On Tue, May 25, 2010 at 10:14 AM, Ricardo Newbery
>> <[hidden email]> wrote:
>>> I'm not sure we can define a
>>> sensible default for the revalidation header for all generic third-
>>> party content items.  In fact, I'm not even sure it's sensible to
>>> assume that it's safe to cache all generic third-party content items
>>> at all... even just weakly.
>>
>> Ok. In this case, here's what I'd do:
>>
>> - Include plone.app.caching into Plone Core (maybe a 4.1 PLIP).
>> - Enable a default simple caching policy for all types.
>> - Add-ons which cannot be cached according to this policy need to  
>> opt-out.
>>
>> I assume 80 to 90 percent of all content types are standard  
>> Archetypes
>> based types, with very little special logic. It's the typical thing
>> you write for every customer project. I want to cache those, not the
>> 10% of fancy composite page or whatever special types.
>
> I think this is sensible, especially if we have an easy way to opt out
> through the GUI.
>
> One option would be to register a very general lookup for
> (IBrowserView, Interface) and (IPageTemplate, Interface) (i.e.
> register one adapter factory twice, or have two variants, but they'd
> be quite similar) instead of the PageTemplateLookup that does
> something like this:
>
> - Attempt to look up a ruleset using z3c.caching.registry.lookup()
> and return that if found. This is necessary because this adapter would
> override the default lookup in most cases
>
> - Get the name of the published object (i.e. the name of the view or
> page template)
> - Find the parent, i.e. a content object
>
> - If the parent is a content object:
>   - Get the default view of the parent
>   - If the name of the published object is the same as the default
> view of the parent:
>     - Look up a ruleset on the parent object (see below) and return
> if that matches
>     - Otherwise, look up the parent type in the content type mapping
> (as PageTemplateLookup does now) and return that if found
>
> - Look up the published name in the page template mapping (as
> PageTemplateLookup does now) and return that if found
>
> The main change here is that in addition to doing a lookup by named
> content type when we encounter the default view of an item, we look up
> a ruleset based on the type of the context. This would allow us to
> register a ruleset for IBaseContent and IBaseFolder, for example.
>
> If we do this, we could potentially hide the content type and template
> mappings from the UI or at least make them less prominent. I think
> they're useful safety valves, though, not at least because you can use
> them to set a "no cache" rule.
>
> Ric, how does this sound?
>
> Martin



Seems okay I suppose.  As long as we post warnings that the default  
policy may now be too aggressive for some third-party content types.

I've been operating on the principle that it's safer to ship a default  
which errs conservatively on the freshness side of the caching/
freshness spectrum.  This would seem to violate that principle...  
albeit perhaps only for Hanno's 10%-20% of third-party types that  
might require special treatment.

So the post-installation burden would change from one where people  
*may optionally* fix any cases where the caching response is not  
aggressive enough to one where people *should probably* check for and  
fix the few cases where the caching response needs to be dialed down a  
bit.  That's a gotcha we probably want to warn people about.

Ric






------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Martin Aspeli Martin Aspeli
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config

On 30 May 2010 02:09, Ricardo Newbery <[hidden email]> wrote:

>
> On May 29, 2010, at 8:43 AM, Martin Aspeli wrote:
>
>> On 29 May 2010 22:13, Hanno Schlichting <[hidden email]> wrote:
>>>
>>> On Tue, May 25, 2010 at 10:14 AM, Ricardo Newbery
>>> <[hidden email]> wrote:
>>>>
>>>> I'm not sure we can define a
>>>> sensible default for the revalidation header for all generic third-
>>>> party content items.  In fact, I'm not even sure it's sensible to
>>>> assume that it's safe to cache all generic third-party content items
>>>> at all... even just weakly.
>>>
>>> Ok. In this case, here's what I'd do:
>>>
>>> - Include plone.app.caching into Plone Core (maybe a 4.1 PLIP).
>>> - Enable a default simple caching policy for all types.
>>> - Add-ons which cannot be cached according to this policy need to
>>> opt-out.
>>>
>>> I assume 80 to 90 percent of all content types are standard Archetypes
>>> based types, with very little special logic. It's the typical thing
>>> you write for every customer project. I want to cache those, not the
>>> 10% of fancy composite page or whatever special types.
>>
>> I think this is sensible, especially if we have an easy way to opt out
>> through the GUI.
>>
>> One option would be to register a very general lookup for
>> (IBrowserView, Interface) and (IPageTemplate, Interface) (i.e.
>> register one adapter factory twice, or have two variants, but they'd
>> be quite similar) instead of the PageTemplateLookup that does
>> something like this:
>>
>> - Attempt to look up a ruleset using z3c.caching.registry.lookup()
>> and return that if found. This is necessary because this adapter would
>> override the default lookup in most cases
>>
>> - Get the name of the published object (i.e. the name of the view or
>> page template)
>> - Find the parent, i.e. a content object
>>
>> - If the parent is a content object:
>>  - Get the default view of the parent
>>  - If the name of the published object is the same as the default
>> view of the parent:
>>    - Look up a ruleset on the parent object (see below) and return
>> if that matches
>>    - Otherwise, look up the parent type in the content type mapping
>> (as PageTemplateLookup does now) and return that if found
>>
>> - Look up the published name in the page template mapping (as
>> PageTemplateLookup does now) and return that if found
>>
>> The main change here is that in addition to doing a lookup by named
>> content type when we encounter the default view of an item, we look up
>> a ruleset based on the type of the context. This would allow us to
>> register a ruleset for IBaseContent and IBaseFolder, for example.
>>
>> If we do this, we could potentially hide the content type and template
>> mappings from the UI or at least make them less prominent. I think
>> they're useful safety valves, though, not at least because you can use
>> them to set a "no cache" rule.
>>
>> Ric, how does this sound?
>>
>> Martin
>
>
>
> Seems okay I suppose.  As long as we post warnings that the default policy
> may now be too aggressive for some third-party content types.
>
> I've been operating on the principle that it's safer to ship a default which
> errs conservatively on the freshness side of the caching/freshness spectrum.
>  This would seem to violate that principle... albeit perhaps only for
> Hanno's 10%-20% of third-party types that might require special treatment.
>
> So the post-installation burden would change from one where people *may
> optionally* fix any cases where the caching response is not aggressive
> enough to one where people *should probably* check for and fix the few cases
> where the caching response needs to be dialed down a bit.  That's a gotcha
> we probably want to warn people about.

I agree - a warning is in order. But I think warnings are in order in
all scenarios. Installing p.a.caching and finding that your site is
brought to its knees as soon as a lot of people visit one particular
page is not really good either. :)

Do you have the time and inclination to try to implement something
like my proposed solution? I'm focusing on plone.app.testing right
now, but I'd like to see this resolved before p.a.caching becomes too
popular to make BBB more complicated.

Martin

------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Ricardo Newbery-2 Ricardo Newbery-2
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config


On May 29, 2010, at 11:18 AM, Martin Aspeli wrote:

> On 30 May 2010 02:09, Ricardo Newbery <[hidden email]> wrote:
>> Seems okay I suppose.  As long as we post warnings that the default  
>> policy
>> may now be too aggressive for some third-party content types.
>>
>> I've been operating on the principle that it's safer to ship a  
>> default which
>> errs conservatively on the freshness side of the caching/freshness  
>> spectrum.
>>  This would seem to violate that principle... albeit perhaps only for
>> Hanno's 10%-20% of third-party types that might require special  
>> treatment.
>>
>> So the post-installation burden would change from one where people  
>> *may
>> optionally* fix any cases where the caching response is not  
>> aggressive
>> enough to one where people *should probably* check for and fix the  
>> few cases
>> where the caching response needs to be dialed down a bit.  That's a  
>> gotcha
>> we probably want to warn people about.
>
> I agree - a warning is in order. But I think warnings are in order in
> all scenarios. Installing p.a.caching and finding that your site is
> brought to its knees as soon as a lot of people visit one particular
> page is not really good either. :)
>
> Do you have the time and inclination to try to implement something
> like my proposed solution? I'm focusing on plone.app.testing right
> now, but I'd like to see this resolved before p.a.caching becomes too
> popular to make BBB more complicated.
>
> Martin


I'm in the middle of a West to East Coast move at the moment.  I  
probably won't be able to get on this till end of June.  I wouldn't  
worry too much about BBB myself... it's still in alpha after all  ;-)

Ric


------------------------------------------------------------------------------

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Alexander Limi Alexander Limi
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config

In reply to this post by Hanno Schlichting-4
On Sat, May 29, 2010 at 7:13 AM, Hanno Schlichting <[hidden email]> wrote:
On Tue, May 25, 2010 at 10:14 AM, Ricardo Newbery
<[hidden email]> wrote:
> I'm not sure we can define a
> sensible default for the revalidation header for all generic third-
> party content items.  In fact, I'm not even sure it's sensible to
> assume that it's safe to cache all generic third-party content items
> at all... even just weakly.

Ok. In this case, here's what I'd do:

- Include plone.app.caching into Plone Core (maybe a 4.1 PLIP).
- Enable a default simple caching policy for all types.
- Add-ons which cannot be cached according to this policy need to opt-out.

I assume 80 to 90 percent of all content types are standard Archetypes
based types, with very little special logic. It's the typical thing
you write for every customer project. I want to cache those, not the
10% of fancy composite page or whatever special types.

+1 to all that. If we don't have defaults that apply for most people, most people won't have caching. It's too complicated. The add-ons that break with the standard setup will have to implement a solution that works.

In general, letting the edge cases guide the design is pretty much always a bad approach.

Thanks for raising this as early as possible, Hanno!

--
Alexander Limi · http://limi.net

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Alexander Limi · http://limi.net

Martin Aspeli Martin Aspeli
Reply | Threaded
Open this post in threaded view
|

Re: plone.app.caching - portal type config

On 5 June 2010 12:09, Alexander Limi <[hidden email]> wrote:

> On Sat, May 29, 2010 at 7:13 AM, Hanno Schlichting <[hidden email]>
> wrote:
>>
>> On Tue, May 25, 2010 at 10:14 AM, Ricardo Newbery
>> <[hidden email]> wrote:
>> > I'm not sure we can define a
>> > sensible default for the revalidation header for all generic third-
>> > party content items.  In fact, I'm not even sure it's sensible to
>> > assume that it's safe to cache all generic third-party content items
>> > at all... even just weakly.
>>
>> Ok. In this case, here's what I'd do:
>>
>> - Include plone.app.caching into Plone Core (maybe a 4.1 PLIP).
>> - Enable a default simple caching policy for all types.
>> - Add-ons which cannot be cached according to this policy need to opt-out.
>>
>> I assume 80 to 90 percent of all content types are standard Archetypes
>> based types, with very little special logic. It's the typical thing
>> you write for every customer project. I want to cache those, not the
>> 10% of fancy composite page or whatever special types.
>
> +1 to all that. If we don't have defaults that apply for most people, most
> people won't have caching. It's too complicated. The add-ons that break with
> the standard setup will have to implement a solution that works.
>
> In general, letting the edge cases guide the design is pretty much always a
> bad approach.
>
> Thanks for raising this as early as possible, Hanno!

After a long delay, I've finally found the time to implement this.
It's landed in trunk now. Review and testing appreciated!

Martin

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers