Am Montag, 26. März 2007 17:40 schrieb Patrice Dumas: > On Mon, Mar 26, 2007 at 12:01:37PM -0300, Avi Alkalay wrote: > > What Ralf doesn't like ? The idea of a central hierarchical configuration > > store, or how the software install itself ? > > Don't know exactly. Ralf isn't interested in elektra, and I think he > is not convinced about the need for such a software. I don't think that > Ralf advice on elektra is such an interesting issue, however. As a side > note I am not convinced by the central hierarchical configuration store > either, I am a no-GUI vi edited text config file in /etc guy myself > (my typical work space is a firefox and a dozen xterms in fluxbox).
I don't think that this workflow collides with elektra. You may use some config file backend, which allowes you a as-is situation with the possibility to solve bugs and performance issues at one place. But you also may edit the configuration with the kdb tool in shell or with python commands (fully fledged python with classes or functions is implemented and hopefully will come with next version). > I clearly don't have any need for elektra, and I guess that in some case > it could get in my way (I dislike gconf, for example). I may have a need > as a programmer to avoid redoing a parser for my config files, but I > guess that it takes about the same time to use elektra or libxml2 > and besides, writing an ini file parser and writer would certainly be > more simpler than the elektra framework. Still I would like to have > elektra concepts and implementation used and tested, it may happen > to be interesting. xml is too complicated and slow if you want only key/value pairs. If you want xml go and use it. Avoid redoing things is the main purpose of elektra. > > >1. include files are in $prefix/includedir/elektra/ (not in > > > $prefix/includedir/) > > > > No problem with this. We can change it in the default spec. > > And in elektra itself? Goes ok with me to change that. > /usr/bin/elektra-kdb > /usr/sbin/elektra-kdbd > /usr/share/man/man1/elektra-kdb.1.gz > /var/run/elektra-kdbd These names are really ugly, hopefully they can be changed back. > > 3. statically compiled kdb and elektra library are not shipped. > > > > > > I think we can completely remove this kind of files from the source. > > Build takes longer and they are not really useful. > > I disagree. If elektra is used in critical apps and dynamic linking > is busted it is very usefull to have a possibility of static linking. Yeah, static linking is important for new libraries, because you can't expect them installed anywhere. But the explict static libraries are not accepted by automake 1.10.x anymore (at least at cpp binding). So we need to remove #AC_DISABLE_STATIC in configure.ac and remove the lib_LIBRARIES = libelektra.a libelektra_a_SOURCES = $(elektra_sources) part in src/libelektra/Makefile.am? Why is it done like it is now? That should be really documented. > > Anyway, developers should use package config for command line build > > configuration. For the kdb tool and other central files, I don't know to > > what rename them. > > The really problematic names are 'kdb' and 'kdbd' they are much too > short and generic. Yeah, but there are solving a very essential and generic problem so the name is warrantable. thank you Markus Raab ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Registry-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/registry-list
