Elektrified X.org released
Posted Nov 30, 2004 19:08 UTC (Tue) by
elanthis (subscriber, #6227)
In reply to:
Elektrified X.org released by khim
Parent article:
Elektrified X.org released
Because real-life users *do* use ext2/ext3, and any system that's intended to be an actual part of common Linux systems needs to take that into consideration.
The "your FS sucks, use the experimental/unstable one I prefer" approach doesn't work. Especially not when you can just fix the system to not *need* a "better filesystem." For example, just store multiple keys in one file. Not that difficult at all. Insanely simple, even.
Multiple files also making transactions IMPOSSIBLE (literally) because there is no way to perform an atomic action touching multiple files. Its as simple as that - with multiple files, the entire database is unsafe, because it can get corrupted and out of sync. Real life applications will have multiple keys that need to be in one of several states, such that certain combinations don't make sense. Without transactions and *guaranteed* atomic commits it would be possible for these states to occur in certain circumstances, resulting in broken applications.
Elektra also lacks change notification (so you still need to restart/signal daemons) and several other important features. As is, the *ONLY* thing it offers is a common API. And given the huge number of existing apps and scripts that will break by switching to Elektra, that common API just isn't worth it. Elektra also lacks features that other apps *need* like change notification or schemas, making it unusable.
The entire Elektra design can be improved upon. In fact, there are better designs already in existance. One (sorry, I forget the name - Config4GNU or something like that) uses multiple backends. So, if you set a key in the X.org namespace, it would load a backend that reads and writes the existing X.org configuration file. The advantage here is that already existing and already in-use configuration utilities continue to work while new applications can use the universal API. New applications would just use the default config backend, which would be some database or file heirarchy or whatever. Because of the backends, the system can inject a daemon that, for example, singles key changes over D-BUS allowing applications to be notified when the user changes something. By using a pluggable backend, the launching of this daemon can be delayed until after the initial system bootup, allowing the config system to be used during early-early boot with reduced features, and then become fully operational once enough of the system is up and running.
Elektra is a nice thought experimental, but it is far from the ideal implementation. It might evolve into a complete solution over time, or it might give way to Config4GNU or some other system.
(
Log in to post comments)