Re: UniConfed Elektra released (was: Elektrified X.org released)
On Thu, 2 Dec 2004 20:00:17 -0500, Avery Pennarun <apenwarr(a)nit.ca> wrote:
On Wed, Dec 01, 2004 at 02:33:27PM -0300, Avi Alkalay wrote:
> 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.
Okay, so I kept my word: I spent a couple of hours today writing a UniConf
frontend for elektra (AKA an elektra backend for UniConf). This allows any
elektra-using program to transparently use UniConf instead.
Uhú! That very good news !
I really wanted to see a UniConf backend to Elektra :-)
- Apparently x.org is already supported, since Avi has patched it
for
elektra. (Technically I didn't try this... just the kdb command-line
client.)
Yep. Give it a try.
- Elektra has a native C API, for you anti-C++ weenies.
- UniConf has a native C++ API, for you anti-C weenies.
We had to do in C due to the project objectives we set.
- Elektra's API is somehow worse than the grotesque x.org
monstrosity.
:-(
I don't think so....
Well, people have a tendency to like what is its own, and dislike others.
The API is very low level, similar to base OS calls. It has to be this way.
- Elektra's API can't do useful notifications except via
polling (or
"simulated polling" - you at least have to keep calling its poll function
to check for changes, rather than it calling you).
Thats because its completely decentralized nature, as far as I can
think about. If you have a daemon you can intercept changes and avoid
polling.
- Elektra's notification support needs work. It should have
registration/unregistration and callbacks, not "call this function
sometimes to see if anything has changed". Trust me, I've been through
this enough times already.
Hummmm... good idea. Will think about it in the flight I have to take
this afternoon. :-)
- The Key data structure should have keyNew and keyFree functions
(allocate
and deallocate keys), not keyInit and keyClose. This would allow you to
make the data types completely transparent, making your library more
ABI-stable. You'll know you've done it right when there are no more
data structure definitions in kdb.h.
Absolut abvious and good idea. How I didn't think about it !
In the end of the flight it will be done.
Hey, Avi, can you convert apache next? Or how about samba? :)
Apache is veeeery difficult, but possible. Samba is easy.
But I'm thinking right now to unify KConfig and GConf backends and
global settings namespace. So font, colors, etc global options will be
shared, and a Gnome app will be able to configure a KDE app. I think
you already have it in UniConf, right? I'll look for your sources
soon. After this, I'll probably dive on Samba.
Have fun,
You too, Avery
Regards,
Avi