Re: Configuration, take2

[Alexey Parshin <alexeyp@gmail.com>]

Well,

Let's kill the INI part. It was my idea but it is too primitive. The
SQL vs XML may be looked at from the position of the implementation.
If the configuration is large - it makes sense to use SQL since it's
probably cheaper to find few needed parameters. Also, database allows
to update just a few parameters w/o blocking the whole thing..
However, if the config is ~ 2Kb or smaller - it may be cheaper to read
the whole thing as XML.

There is one more solution, too. It's possible to create a config
server :) That would be a combination of two approaches. An object
that would access such server should just always request needed
parameters, and doesn't have to load the whole config file. The
interface could be like:
   servlet.connectToConfig("ServletClass:configClass");
   CParam p = servlet.getParam("Param1");
   servlet.getParam("Param1") = p;

On 4/26/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> So there are three propositions as to how exactly to store configuration.
> 1. Use XML
> 2. Use SQL database
> 3. Use INI format
> 
> Each of them have advantages and disadvantages, so think right thing to
> do is to provide
> generic interface, and few implementations.
> 
> Now, there are few choises as to interface itself.
> 1. Provide very generic chierarchical interface:
> config.getNode(parent=NULL, name)
> node.getParam(node,name)
> 
> 2. Provide somewhat specialized interface
> config.getParameter(name)
> config.getApplicationList()
> application.getParameter(name)
> application.getServlets()
> servlet.getDSOPath()
> servlet.getParameter(name)
> 
> 3. Provide strictly structured interface
> Pretty much same as 2, but also provide mandatory params
> i.e. config.getDefaultSessionTimeout();
> application.getSessionTimeout()
> application.getName()
> application.getDesc()
> 
> Thoughts?
> 
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
> 
> 


-- 
Alexey Parshin,

Senior DBA,
Tactical Telesolutions,
San Francisco