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 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. 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 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. 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. Now if we rely on fuse/unionfs daemon become probably useless ... Be sure i'm sure of nothing :-) I simply expose idea i have for discussion. > 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 : kdbGetChildKeys(KDBHandle=handle, system/, KeySet=returned, options) { (from kdb.c) int maxDepth; mapping = bmGetBackendFor(system/, handle->mapping, &maxDepth); // mapping for system/ will be associated to filesystem backend // maxDepth is computed by bmGetBackendFor() in function of what the handle->mapping table contain. // In this case, maxDepth is 0 since there is a mapping about system/sw -> Filesys don't have to recurse in all // directories cause of this mapping. So filesys could only fetch the first level of system/ -> maxDepth = 0 mapping->backend->kdbGetChildKeys(mapping->handle, system/, returns , keysDirs, RECURSIVE, maxDepth) // keysDirs contain dir keys fetched by kdbGetChildKeys _ONLY IF_ maxDepth != -1 (infinite). Otherwise its empty. // So in our case, keysDirs will contain : // system/sw // system/init // system/elektra // // while "returns" contain keys asked by user throught the "options" parameter (only dir, stated only, follow symlinks, ...) foreach keysDir as key (here we are using ksPop() for remove read "key" from the keysDir keyset) // Get mapping associated to the given key // // for system/sw --> berkeleydb, maxdepth=-1 (infinite, since there is no other mapping after system/sw) // for system/init -> filesys, maxdepth=-1 (infinite, cause is same) // for system/elektra -> filesys, maxdepth=-1 (infinite, cause same) mapping = bmGetBackendFor(keyStealName(key), handle->mapping, &maxDepth) // Since there isn't more mapping under each of these keys, no key will be added to keysDir // and foreach loop will end when no more key are in keyset mapping->backend->kdbGetChildKeys(mapping->handle, keyStealName(key), returns, keysDirs, RECURSIVE, maxDepth) end foreach return } Hope this will help to better understand the idea. 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 ;-) Regards, Yannick. ------------------------------------------------------------------------- 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
