Hi,
Avi Alkalay wrote:
> Can anybody tell me why we have a full ltdl library inside Elektra's
> source? Isn't it the OS responsability to provide one? Does Linux
> provide one by default ?
if i understood things correctly, libltdl could be used either in three
form :
* An embeded form : the form we're actualy using, also know as
convenience).
* An installable form : configure script check if a libltdl is
existing. If yes it will use it. Otherwise, it will compile and install the
embeded libltdl on the system and then use it. Note this mode need
to keep the embeded form of libltdl too.
* Manualy : Simply add -ltdl to *_LIBADD
I made the choice to always use the embeded form for
dependency/simplicity reason (here, libltdl is in /usr/lib)
You can found more information about that here :
http://www.gnu.org/software/libtool/manual.html#Distributing-libltdl
> About 1 simple configuration file to define the default backend, seems
> a bit dirty for me. Anyway I think this idea should not be discarded yet.
I think that's not as dirty as it could look. Indeed, today most
settings are simply hardcoded. Imho that's more dirty than have a
configuration file.
If i would store my entire configuration stuff into /config/ for some
reason, i have to recompile backends. There is actually no flexibility.
Defining default backend using symlinks rather than fetch its name from
a configuration file is dirty too for at least two reasons :
* On system which doesn't support symlinks, What other solution we have
other than _copy_ a backend shared object to libelektra-default.<ext> ?
Then its not really simple to know which backend this default backend
is. Your only choice is to use kdbhGetInfo() for know its true name ;
* Imagine you want to change default backend (like hot-plug) : have to
remove and recreate the symlinks could produce some strange behaviour.
Between the remove and re-creation of the symlinks, there is lap of time
where no default backend is defined. What's happen if an application is
launched and try to read its configuration or, event worst, if a running
process do a kdbOpen() ? Things could goes good (kdbOpen() simply return
an error code) but they can goes bad as well (segfault ?). Depend of
low-level implementation of the underlying OS and the actual context.
With an elektra configuration file, you could simply edit it and change
the default backend's name. Then, eventually, send a -HUP to running
applications and things will simply works as expected. There is still a
race condition, but this one could be simply removed using locking.
In a full static context now : actually the default backend is defined
at compile time. Imagine a system with tons of software staticaly linked
to libelektra. In a such system, if you want to change the default
backend you have to re-compile elektra and re-link all these softwares.
If we were
using an elektra internal configuration file, kdbOpen() know the true
default backend's name and then be able to load it. Moreover, since we
know the true backend name, we could use libltdl to manage static
dlopening rather than our current hack which require to compile
everything twice.
Perhaps this idea
http://article.gmane.org/gmane.comp.lib.elektra.devel/23 is a bit "too
much" today. We could simply begin with a "dumb" flat configuration file
and start to define a scheme for allowing elektra and backends to have
some "dynamic" parameters.
Regards,
Yannick.
-------------------------------------------------------------------------
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
