Elektrified X.org released (was: X configuration paradigm, and a proposal)
apenwarr at nit.ca
Wed Dec 1 22:25:22 EET 2004
On Wed, Dec 01, 2004 at 02:33:27PM -0300, Avi Alkalay wrote:
> - It is very difficult to implement hierarchy in a consistent way inside a
I've done it. I wouldn't want to do it too many times in my life, but it's
really not very hard, and BDB has transactions and locking, so it can be kept
> - 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.
This is simply not true. Simply use Unix domain sockets and cookies, as
Sean says. UniConfDaemon already does this. So does DBUS. And X, for that
matter, the source code to which you've already been hacking.
> - 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.
I'm starting to feel more and more like I should write an "Elektra" frontend
for UniConf. Now that you've actually done the work of converting x.org to
it, I'd like to be able to configure the X server using any of UniConf's
supported methods: trees of files, ini files, daemon or non-daemon, dbus,
gconf, kconfig, etc. This would even help your "Elektra is just an API, the
actual implementation could be done any number of ways" point... by
demonstrating it :)
I'll see how motivated I feel later.
More information about the xdg