On Tue, 30 Nov 2004 13:57:01 -0500, Sean Middleditch <elanthis@xxxxxxxxxxxxxxx> wrote: > Getting intricate behaviour with shell scripts is also quite possible. > You would probably need some kind of service daemon. So you'd write > something like: > > #!/bin/sh > > # this would print out code to set an environment variable, so the code > # gets executed by eval, setting the variable > eval(kdb begin) > > # set some keys - the command would check for the environment variable > # defined by the shell service daemon, and communicate with the daemon > kdb set "key1" "value" > kdb set "key2" "value" > > # do some other stuff, including checking values of keys, which would > # also communicate with the daemon if the env-var is set > if [ `kdb get 'key2'` = 'value' ] ; then > do-some-stuff > set-some-other-keys > fi > > # commit/rollback/whatever - again, checks env var, daemon, etc > kdb commit > > #eof Instead of doing a lot of 'kdb set', you can generate an XML file with the keys you want changed, and do 'kdb import keys.xml'. It will be more atomic, and will use the kdbSetKeys() call which wraps transaction support. > The daemon would take some work to get working robustly (i.e., noticing > when its parent exists without shutting it down, and thus shutting > itself down cleanly after doing a rollback op, etc.) but its certainly > possible. > > > > > > About storage, 1 file per key or 1 file per folder uses almost the > > > same amount of disk space. Do a 'du -sk' in gconf storage folders to > > > see that. > > > > In a db4 hash overhead seems to be percentage points. In flat file its > > about 3.5K per key for single key per file. It is implementation detail > > compared to the fundamental goal. > > The author has this unfortunate tendency to use ReiserFS and other non- > mainstream file-systems and claim everyone else should too (Linux > Registry, the previous name for Elektra, was shot down repeatedly due to > his disregard for real-life systems) so he probably doesn't see any of > the over-head for small files. I don't have a tendency to use ReiserFS, but it showed to be more performatic and less space consuming then any other FS. And I do see the overhead for small files. The point is: only discussing ideas is very different that writing code. In this last case you'll find issues that destroy entire architectures you built in your head. A single DB file and a deamon was obviously the first reasonable thing to think and to implement, so read bellow. > A db4-baed system certainly has technical advantages in terms of > efficiency, but stop and think - you're basically now running the > WIndows Registry. The Registry's *largest* problem is that it's a > binary format that easily gets corrupted - a lot like Berkeley DB (hell, > I wonder if that's what the Windows Registry's code is based off of > ~_^ ) Yes, this is one problem with BDB. BDB was the first thing used, and droped in version 0.0.9. See the changelog: http://www.germane-software.com/repositories/elektra/trunk/ChangeLog The major problems with BDB or a daemon (that was also the paradigm for the old old old versions) are: - It is very difficult to implement hierarchy in a consistent way inside a BDB - Elektra is system-wide by definition. So with a global daemon, security has to be handled in the user-space daemon. And security is a little thing that you may require this: is the best (kernel space) and you have it, or you simply don't have it. - Besides, you can't authenticate against a system daemon. Authentication means to have a user to *type* a password or *read* it from a file. Think about how authentication works in HTTP sessions, LDAP, DB servers, etc. I'm open to hear ideas on this point. - A daemon is a single point of failure. These were the reasons why daemon and a single file (binary or text) is accepted only in non-critical, desktopish, single user environment (read GConf, that really makes its job!). Not systemwide. > The best format is probably something like XML, or something very XML- > ish, because it can easily store a hierarchy in a single file, is "safe" > in terms of value escaping (many custom formats are not), and there are > tons of libraries to read/write it efficiently. It isn't *easily* > edited by hand, but if it's "pretty-printed" it can be easy enough. Read/write in memory, not on the disk. On the disk you have to rewrite the entire file, so bye bye transactions. > > Overall I'm glad to see this work being done. I'm not convinced the format is > > right but the essential goals of unifying configuration spaces, improving > > tools and also just going out and doing it are all good things. > > Definitely. Elektra still has major short comings (no transactional > guarantees, no notification, no real access control, no temporary > keys... mostly things Elektra can never do since it refuses to use a > daemon), but it's at least a tiny step in teh right direction that might > open some peoples' eyes. Notifications is there already. Check the code. Transactions needs some stabilization, yes. What do you mean with "no real access control"? This is completelly delegated to the best guy that can do it: the Kernel. And what do you mean about "temporary keys" ? > Sean Middleditch <elanthis@xxxxxxxxxxxxxxx> > AwesomePlay Productions, Inc. Thank you, Avi
