[dev] [cvs] commit: horde/docs CHANGES framework/Horde/Horde Registry.php

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>>  1. First, remove config file caching.  Config files are straight forward
>>  and reading them in is a simple PHP parsing activity, so any benefit in
>>  caching is minimal at best.
>
> I disagree. This might be true for plain, generated config files. But
> as soon as you have a more complicated, customized setup, you might
> end up with all kind of logic, database requests, etc. in the config
> files.

The original thought yesterday, especially with horde files, is the  
chicken-and-egg problem: how to determine the cache setup until we  
parse the horde config file.  But after a night sleeping on it, I have  
realized that this isn't a problem.  After we store a config file in  
the cache, we can save the necessary cache config information in the  
'_registry' session variable to allow us to immediately access caching  
on the next session access.

While on the topic - do we still want to allow registry changes to  
real-time affect sessions?  No other config changes (prefs, config -  
once I re-add the caching code) affect the session, so registry is an  
outlier in that regard.  And it adds a not-trivial amount of overhead  
when it comes to having to scan all the registry directories on every  
session access.  IMHO, changing permissions or view status during an  
active session is a bad admin practice anyway.  If the intent is to  
shut down modules/horde from access, there are other better ways to  
accomplish this.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]