Elektra's technical suitablity

[Avi Alkalay]

Exactly. Since Elektra was designed to absolutely any type of
software, even to no-software, we tryed to keep it as simple as
possible. The more we optimize it for some specific need, we
deoptimize it for some other.

However, you can put some layer of schematics on top of it. This is
exactly what GConf with Elektra as its backend is: use GConf API,
GConf namespaces, GConf semantics, GConf schemas, and Elektra only for
the storage and sharing with everybody else (KDE, etc).

I personally think schemas add too much complexity to the application
programmer, make his life more difficult, and inhibits him to interact
with other softwares configurations. But this is my opinion and we
don't have to discuss that....

Avi

On 4/2/06, Shane Stixrud <shane at geeklords.org> wrote:
> On Sun, 2 Apr 2006, Joe Desbonnet wrote:
>
> > As far as I can tell Elektra does not support configuration schemas.
>
> If I am not mistaken Elektra currently treats all plain text key values as
> strings. I think this is a feature and not a limitation.  Elektra is
> friendly towards existing application configuration schemes. If it
> enforced key types (Integers, floats, strings etc...) things get a lot more
> complicated and it is not clear this is the right place to enforce it.
>
> Perhaps enforcing the input types at a configuration builder
> API makes more sense, keeping libelektra free of the added complexity?
>
> Cheers,
> Shane