On Tuesday 27 February 2007 13:01:50 Markus Raab wrote:
> 27. Feb. 2007 12:28 Joan Valduvieco Llopart wrote:
> >Avi wrote:
> > > The daemon backend and /sbin/kdbd should be included in main package,
> > > the same that contains filesys.
> >
> > Why include daemon backend in the main package?
>
> No, it should not of course. Without the daemon-backend the daemon does not
> make any sense.
>
> The utils should also be separated (as now), it actually makes sense to
> have libelektra without the kdb utility.
>
> > Main package should be just the library and essential binaries.
>
> There is no essential binary.
> The kdb tool should be provided by default when elektra is installed (meta
> package, suggest,..), but it is not essential.
>
> Others may mean they can't use elektra without their favourite gui editor
> and others may say the xml import/export is an integral part of the elektra
> environment.
>
> So I would say that the real dependencies count.
>
> > Daemon backend, from my point of view, is not essential.
>
> Full Ack
>
> > Right now I'm using libelektra on an embedded device that is using
> > filesys backend and doesn't need 'kdb' as my binaries have direct acces
> > to library API.
>
> Exactly.
>
> > I understand that 'kdb' can/will be useful to query kdb from shell
> > scripts. I think that this scenario is the minimal functional scenario,
> > isn't it?
>
> When you want to write elektra shell scripts you need libelektra-utils. I
> don't see any problem with that. Packages using libelektra and having
> pre/post install scripts need of course a dependency to libelektra-utils.
>
> Others without scripts may not need it...
>
> > Maybe I'm missing some locking issues that make filesys or berkeleydb not
> > useful when queried from multiple binaries?
>
> No, elektra is very useful from multiple binaries with backends which
> provide some locking (there might be some bugs in it). But there are some
> problems with multithreading, I am working on that.
>
> > Yesterday I was reviewing daemon backend code. kdbd backend can be
> > configured using a 'configure' parameter (--with-default-dbackend) which
> > sets DEFAULT_DBACKEND preprocessor define.
> > Wouldn't be more useful if this parameter could be set using a run time
> > parameter or an environment variable? This way could be configured
> > using '/etc/default' debian mechanism permitting kdbd's backend selection
> > at startup. Does this make sense? I can do the patch if necessary.
>
> Yeah, it makes sense for now. But is the KDB_BACKEND used in kdbOpen not
> enough? The daemon could have another KDB_BACKEND environment set then the
> application using the daemon-backend.
That would be great. It was my initial idea but reviewing code made some
interesting discoveries.. ;) As can be seen on kdb_wrapper.c:62
/* Opens the default backend for daemon */
real_backend = DEFAULT_DBACKEND;
ret = kdbOpenBackend(handle, real_backend);
error = errno;
kdbd uses DEFAULT_DBACKEND define as backend. It uses kdbOpenBackend which
does not use environment variables. I'll issue a patch to check environment
variables.
>
> But the long-term view is of course that elektra supports multiple backends
> at once by mounting them. This would obsolete the environment variable and
> will make it possible that every program can access the whole elektra
> namespace.
Oki understood. Seems interesting the concept of mounting backends.. :)
>
> 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
