Re: Configuration, take2

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

Wait wait... Why are we even talking about "changing". Generally I presume
that if config is changed, it is changed by admin, and then whole domain
that
change affected gets reloaded. I.E. if it was servlet-specific param,
servlet is reloaded
and if app-level, then all servlets in that app... In case of Java-based
app servers,
whole app is always reloaded (and in case you change one of server
config files,
it's your job as admin to make sure server finds out about that).

In that light, it makes no sense to keep config itself (as in "XML DOM")
in memory. Instead there
are certain objects that get created as a result, and they exist as long
as their domain exists.
i.e. right now I only have one ServletContext - it's just a static
variable that is initialized on startup.
However, when we create whole "Application" support, there will be
multiple contexts - one per app.
App-level parameters will be kept there. Then there is ServletContainer
object - these can keep per-servlet
params. etc.

Alexey Parshin wrote:

>I'm not that concerned about enforcing yet. However the speed and ease
>of use for the 1 is the best. We keep everything in memory, we save
>changes from time to time. Every changed option group can be
>validated, and we can always define the validation routine.
>
>On 4/26/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
>  
>
>>Or use interface #2 or #3 from original email,
>>which actually force you to have some options present/accessible.
>>
>>Alexey Parshin wrote:
>>
>>    
>>
>>>Not sure. We may request a list of options that must be defined as a
>>>property of the option group.. I don't really like it, but that would
>>>work
>>>
>>>
>>>On 4/26/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
>>>
>>>
>>>      
>>>
>>>>So, you are sudgesting interface #1 to config?
>>>>i.e. 100% generic config functions? What kind of
>>>>enforcement mechanism on presense of config options
>>>>shall we have then?
>>>>
>>>>Alexey Parshin wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>In this case, we only have one copy of the config in memory, and the
>>>>>solution is simple - it should be hash-tree in memory, stored as XML
>>>>>when updated. We don't even need to store it on every update, only
>>>>>after some period of time, to ease the disk load. And access to such
>>>>>thing could be something like:
>>>>>
>>>>> CConfig& servletConfig = configuration["servletClass"];
>>>>> CParam& param = servletConfig["my_param"];
>>>>>
>>>>> param = 12345.67;
>>>>> /// ...
>>>>> CString strParam = param;
>>>>> int intParam = param;
>>>>> double doubleParam = param;
>>>>> /// ...
>>>>>
>>>>>          
>>>>>

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com