[development] Caching, caching, caching...

[Gordon Heydon]

Hi,

Remember also modules like organic groups which has no relation to roles.

Maybe a caching flag on theme('page'), so the modules can determine tell 
the system to cache this page for this user, or groups of users.

I know that we just return something, so we would need to make the 
return method to allow the returning of an array which is past to 
theme('page');

Gordon.

John Handelaar wrote:
> Dries Buytaert wrote:
>>
>> Cache by role doesn't work because there are many per-user settings 
>> (eg. language preference, the username in the navigation-block, etc).
> 
> 
> To be fair, I did *explicitly* mention that would be some
> elements which could not be cached by role.
> 
> There are, however, a whole bunch which can - I'm confident
> in my original assertion of 'vast majority', in fact.
> 
> That there are some places it can't work doesn't sound like
> a good reason to not consider the places where it can -
> unless we're going to keep thinking of caches as a full-page-
> only thing.
> 
> i18n/l10n, as you say, would probably have to be another "vary"
> switch.  This implies that we should maybe be thinking about
> a new core hook, which modules can use to introduce/manage switching
> cases.
> 
> How about stepping back and thinking about what variables can
> affect caching on any given theme() function, and in which order
> they do so?
> 
> eg
> 
> 1.  (core) Role, and if not role then
> 2.  (core) User, and if not user then
> 3.  (i18n module) $some_i18n_variable, else
> 4.  ...what else?
> 
> 
> Actually, that list might be upside down in practice, but
> hopefully I've managed to get my point across.
> 
> 
> Cached values would be returned for any function which
> returns theme output... like...
> 
> [pseudo-code]
> 
> function node_page_default() {
>   global $user;
>   if (node_page_default_cache($user->uid)) {
>      return node_page_default_cache($user-uid);
>      }
>      else {
> 
>      // original function here
> 
>      }
> }
> 
> ...where node_page_default_cache() would be an implementation
> of hook_cache(), which in turn contains that order-of-preference
> logic mentioned above.  $user->uid gives us the ability to
> check roles, uids, and anything else we might need.
> 
> This would involve changing *lots* of functions, I realise,
> but consider how many DB queries we'd be culling.
> 
> On the other hand, a well-written hook allows modules to
> start using it incrementally - modules which haven't implemented
> it yet don't fail.
> 
> 
> 
> 
> 
>