Linux Registry -> Elektra Project

[Thomas Leonard]

On Sat, Nov 06, 2004 at 06:51:53AM -0300, Avi Alkalay wrote:

[ entry on Linux Registry ]

> Would you please updated it:
> 
> - Project name changed: "Elektra Project" http://elektra.sf.net
> - Elektra provides a sigle unified system-wide namespace to represent
> keys, and a clean API to access it, with many language bindings.
> Please put this as the main reasons for the existence of Elektra if
> you can.
> - It has absolutely no dependencies on higher level libraries, by design.
> - It not a single point of failure, by design.
> - The one file per key is one possible implementation, and it can
> evolve to something else, with no API change.
> - Elektra supports change notifications and locking.
> - It is well documented with all API doxygened. It has many language bindings
> - It is the only (as far as I know) proposal that tryies to solve
> configuration problem system-wide, and not only in the desktop.
> Although for a desktop usage it needs some aditional layer of
> functionality, so this is why Elektra may be the common backend for
> KConfig and GConf.
> - Project members are working on patches to elektrify /sbin/init,
> X.org, KConfig, GConf, modprobe, etc.

OK, updated. From the new page, I have a few questions:


"API supports change notifications and multiple backends."

Nothing more is mentioned about this in the document. How does change
notification work? Will it work over NFS, on BSD systems, etc?

It says:

"Is NOT something that accesses SQL/relational databases."

But later, it suggests that this is a goal (or at least possible):

"For Windows, a Registry storage backend is needed."


"user:aviram/env/env2/PS1"

Is there a well defined convention for doing lists? Eg,

user:aviram/env/#1/PS1
user:aviram/env/#2/PS1
user:aviram/env/#3/PS1

Such that deleting #2 would rename #3 to #2, or something, to keep the
list continuous?


When comparing to other systems, it says of them:

"Very small applications must open their database to get values. Elektra
will only open very small files when requested; one file per key."

This actually seems to be a disadvantage of elektra. Usually, apps want
all their keys, so opening one file is faster. But even if an app only
needs some keys, mmapping the file and reading just the required pages
will be faster than opening each key separately. Keeping everything in one
file also means the OS is more likely to keep all the data together on the
disc.

"An application that uses the registry must scan many keys to find the one
it is looking for. Elektra uses the fastest scan engine available: the
file system. There is nothing to scan; given a key name, it is mapped to
its corresponding file, and then opened."

It's not at all clear why the filesystem is the "fastest scan engine
available". Switching to kernel space and doing access control lookups for
every node in the key path suggests that a pure user-space solution would
be faster, at least for db files (not for plain text, of course).


-- 
Dr Thomas Leonard		http://rox.sourceforge.net
tal at ecs.soton.ac.uk	        tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1