Re: [Registry] Hierachy

[Avi A. <avi...@gm...>]

> There are a lot of files now in the root of elektra
> markus:~/Projekte/Elektra/svn/elektra$ find . -type f -maxdepth 1 | wc
>      35
> 
> and they will be getting more :-)

Hummmm, I have
$ make clean
$ find . -maxdepth 1 -type f | wc -l
19



> What about giving source files into /src like common in many projects?
> 
> I would also suggest giving the kdb (1) shell command into a subdir.

If you want to do that, propose something and send us a tarball to test.
I think sooner or latter we'll need it.



> btw. In the changelog Avi, you say:
> - Added documentation on how to write new backends
> 
> Where can i find that?

Here!!! In the detailed description section:
http://elektra.sourceforge.net/elektra-api/html/group__kdb.html

But don't expect too much :-)
I forgot to upload to the web, after I included it.


> It would be also a very good thing to split the localkdb.c into one file
> specific to the accessing the database and the rest. I plan to write an
> backport with .ini style, but dont expect that it will happen today or
> tomorrow :-) And giving the functions which have to be changed for an port in
> its own source file would make it much easier!

Yes, you'll see that there are 3 tiers of code:
- 100% backend dependent code
- code that can use backend features to get performance improvements
(but are generic today)
- 100% backend independent code, like the entire Key and KeySet classes.

I was thinking to split localkdb, but I don't know how to handle the
mid-tier in compile time. I was thinking something like: if a backend
code has a better implementation of method XYZ, use it. Otherwise, use
the generic implementation. I have no idea how to do that, and to be
simple and elegant in the compile time. Any suggestion ?

Markus, I saw your last update.
Are you sure it is better to leave pre-generated Debian manpages on Subversion ?

Regards,
Avi