Am Mittwoch, 13. September 2006 11:28 schrieb Yannick Lecaillez: > Avi Alkalay a écrit : > > Yannick, I think a document like this was missing to organize some > > ideas thowards mounting points. > > You're right, in fact this document was firstly written for myself : > write down my current vision of what could be multiple backends into > elektra. I started it as a document to make a proposal but i continued > it as a "misc-idea" for myself. I planned to rework it a bit before > publication, but since the discussion about multiple backend started i > would give a state of what i thought. As i said this doc is published > "as is". Perhaps i made an error to post it in a so early stage (?).
I think its a good start. Everybody is welcome to contribute and bring ideas. We should now start to discuss technical details and implement them as soon as possible to see if it works out. > > I still have many doubts regarding directions for this. For example, > > will config mount points be available for non-daemon environment? Does > > it makes sense at all? Etc.... > > I've probably same doubts :-) This document was written before the born > of kdbd. In fact its still not clear to me in which level this have to > be done. In a linux-centric vision, we could consider rely on project > like "fuse" and "unionfs" for externalize the storage problem. I mean, > we could simply keep the filesystem as the only backend but mount > /etc/kdbd and ~/.kdb using unionfs mounting a berkeleydb fuse filesystem. It should be inside the library, but not in backend code. user app -> elektra -> mapping code -> resolves correct backend -> backend > Go here for a quickview of what is unionfs : > http://www.linux-live.org/unionfs/ > Go here for a filesystem into database FUSE component : > http://cpan.uwinnipeg.ca/htdocs/Fuse-DBI/Fuse/DBI.html I don't think fuse can help us. It will need costly syscalls anyway and is a linux-only thing. A filesystem which can handle small files efficent would be perfect, but is utopian. > In the multiple backend mapping system, you're free to use or not > daemon. You could simply map everything to filesys-backend. Only one > mapping isn't overridable its the "system/elektra" tied to filesys > backend : this way elektra could fetch its own configuration in every case. Which leads again to the question if we really need a configuration. What if only filesys (or similar) is used. Then you don't need it. What about having a root (/) with underlying system, user and conf (for configuration of elektra)? Things can added then more easily in future (like doc, local...). > The main idea which motivate multiple backend system is to allow elektra > usage at early bootstage using low-level stuff (filesys) while allowing > a more 'powerfull' usage of elektra using more higher-level stuff > (berkeleydb, ldap, sql) trought daemon. And yes, i think this point make > sense. Is it absolut essential that we have it. Now there are only 2 options: Lets remove completely the ability to load backends and every app is tied to a specific backend. Lets take the step and make several backends at once possible in the same namespace. This is what the proposal describes. > Now if we rely on fuse/unionfs daemon become probably useless ... Can you explain that please? > > From your document, I don't understand these extra parameters to > > kdbGetChildKeys(), like maxDepth and keysDir. Can you clarify ? > > These are hints for the backend. Example : if you > kdbGetChildKeys(system/) recursively and if there is a mapping like : > > system/ -> filesys > system/sw/ -> berkeleydb > > Here a pseudo-code of what will be done : I think we can simple write it now. Code is quite unstable anyway if I get Avi correct. > Be sure i'm still really open to very different vision : i'm sure of > nothing here, that's just proposal. The only things i'm sure is we'll be > flamed if we launch a setuid-root kdbd trought libelektra-deamon.so ;-) I am not really interested in a setuid-root daemon for configuration;) Silly question, why not setuid-elektra.elektra? thank you Markus Raab ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Registry-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/registry-list
