On Tue, 2004-11-30 at 12:17 -0500, Alan Cox wrote: > On Tue, Nov 30, 2004 at 01:34:47PM -0300, Avi Alkalay wrote: > > > > > 3. You might run out of disk space > > > 4. You need rollback > > > > So the app handling the keys must be mature enough to roll it back. > > In ten lines of shell script. Rollback belongs in the configuration libraries > so you can do commit(list of key changes). That handles out of disk for > free also. Indeed. Any configuration system like Elektra basically needs some real database functionality. This isn't a problem - it's 100% possible. Elektra just needs to export the API, and leave the implementation details of it to the backend. A Berkeley DB backend for example could easily implement transactions and such. (Or do you need one of the commercial BDB variants for those?) Looking at the API, it appears that Elektra is already pretty much "there". Just grab a KeySet, set the keys, and save the whole set. You just need to guarantee that saving a set is atomic. i.e., make sure everyone backend does this, and clearly document this. So far as implementation, this really is easy even with a (single) file- based backend. Robustness might take some work, but the basics are easy. You simply keep a list of all they keys that have been set, and when the Commit command comes along, lock the file(s) in question and modify them. On Rollback, just "forget" all the key changes that haven't been committed yet. Basically the hard part for the simple file backend is getting the commit to stay atomic on errors when you use multiple files. If you have multiple files being changed, I don't believe it's actually possible to be 100% atomic - you can reduce the chances of something breaking, but there will always be various race conditions in regards to when errors occur that could leave you in a half-committed state. 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 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. 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 ~_^ ) 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. > > 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. > -- Sean Middleditch <elanthis@xxxxxxxxxxxxxxx> AwesomePlay Productions, Inc.
