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

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> 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.
>
> Eh... thinking more about this, I was right the first time.  We  
> can't cache the horde config using Horde_Cache because we have no  
> way of grabbing the cache config before loading the horde config.   
> Obviously, the horde config isn't loaded yet and (the part I  
> forgot), $_SESSION isn't loaded yet either.  And we can't load  
> $_SESSION until we load the horde config since we may have  
> configured a custom session handler.
>
> So I've added support (not yet committed) for caching an  
> application's full config array, but not the base horde config.

I'm still in favor to keep this in the session until we have a smarter  
policy architecture. The config is not really that huge of a dataset,  
compared to the registry and the prefs.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/