Elektra 0.7.0rc2

Carsten Haitzler (The Rasterman) raster at rasterman.com
Wed Mar 26 12:22:15 PDT 2008

On Wed, 26 Mar 2008 12:28:41 +0900 "Daniel Bo" <daengbo at gmail.com> babbled:

> Gustavo,
> Do you have any comparisons of the advantage of using this instead of
> > EET[1,2]? Enlightenment is using EET for a long time now and things
> > just work, it's easy to use and performs well, does not depend on
> > external libraries.
> >
> > [1] http://wiki.enlightenment.org/index.php/Eet
> > [2] http://www.enlightenment.org/viewvc/e17/libs/eet/
> >
> I don't really know either project, but looking at the pages suggests that
> Elektra doesn't seek to do away with plain-text configuration files, but
> rather have a library which parses those files and presents the
> configuration information in a hierachical manner, much the way /proc does
> for the inner workings of the kernel.
> I think it's admirable, but not likely to work because of the enormous
> number of configuration files that need to be worked with.

doesn't work like that. it has a core file format. its' zip-like with a header,
directory table os string -> file offset and the chunks of data optionally
compressed each and a shared string dictionary per file to save decoding and
copying the same string everywhere on decode.

the bit gustavo was talking about was that it ALSO can take in-memory data
structures (structs of int's char's, shorts, floats, doubles, char *'s, linked
lists, hash tables ....) and serialise and de-serialise again.

so you may split your config up between multiple eet files - each eet file
holding config for a specific use case that gets modified at once generally
(it's built around write-once read-many style use, so when u modify something u
rewrite the whole file - eet handles that for u in READ_WRITE mode though), and
then u'd have that file have multiple keys in it, and each key maps to some data
struct serialised that then holds more info.

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com

More information about the xdg mailing list