On Thu, 2 Dec 2004 20:00:17 -0500, Avery Pennarun <apenwarr@xxxxxx> 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
