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@xxxxxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
