Am Freitag, 20. Oktober 2006 14:33 schrieb José Luis Tallón: > Markus Raab wrote: > > libelektra is probable to be continued as a university project at TU > > Vienna during the software engineering 2 lecture [0]. > > > > Current we are 3 People trying to continue the project relating: > > * ability to mount backends > > Please elaborate a bit more on this
Its like the draft written from Yannick. The idea is quite old, but there is no implementation (or technical description) how to actually do it. Relatively fixated is that kdbGetKeys will be redesigned to contain the recursive code. So the flags hiding .* files will also went there. Backends will have so much less code for kdbGetKeys. When walking recursive through the directorys it searches for mount points, in that case it uses another backend for that subdir. > > * API rework > > - mark functions to be necessary for bindings > > - mark obsolete functions > > - improve documentation > > most needed! Yeah, always. But avi did very good work! > > - writing test functions > > - mark c-helper functions > > * make kdbHandle binary compatible > > This might not be needed... but a stable (and future-proof, and secure, > and efficient) API is a MUST right now. Until there are not all features implemented (and mounting ability is a must have) it is not possible to guarntee the api to be completely stable. But things like registry -> kdb renaming won't be done, the 3 classes concept, kdb*, ks* and key* will stay. But using hashes for keysets and the mounting ability will need some changes I am afraid. > The threads on Elektra architecture should be reviewed, a design needs > to be completed and then we can go on implementing every remaining bit. Very good point! I will try to get the multithread thing also in. > > * ini backend > > * cpp bindings > > * python bindings > > * scheme binding > > * (with example apps to bindings) > > Ok. I would suggest C++ and Python to be the highest priorities, Perl > and Scheme can come later. We have Scheme expert here, so its not really a question for what is needed. > > additional (if we have time or it is needed): > > * notification system + scheme binding > > The notification system (probably inspired on FAM API) is badly needed > if we want applications to be responsive to changes without a complete > restart / config reload. This needs API restructure too ;) > > * benchmark for large keysets > > * debian packages (one is debian maintainer) > > I will help on this ;) Would be very nice! Getting it into unstable would be a big step! > > Questions: > > Do you have other ideas to have elektra improved? > > (coding work only) > > Complete the design first: elektra daemon, backend "layering"/mounting, > security considerations and the like are all to be taken into account. The deamon brings the security problems, so you won't be forced to use it. But when you have a mount point for daemon, all subdirs will be managed by the daemon. Mmh, small recursive problem here ;) > > Shall we fork elektra or directly work on svn? > > I suggest a branch in the SVN repos. When we decide to fork we won't use SVN. > > We can't find broad conventions, that means we three will decide how to > > do it, and what to do. After the work it is of course possible to patch > > out things which can be done in a better way or are too incompatible. On > > the other hand its also possible to get the patches into the main branch. > > (This might be so complicated that it will not be done, e.g. if there is > > a api change in fork, I can't make the scheme binding work for pre-api > > changed elektra) > > Please devote enough time to planning and coordinate with "upstream" > proper [upstream being mostly Avi, Yannick and you, I presume]. > Otherwise we would only be wasting everybody's time. The bindings are very easy to bring in. The API and docu restructure is nearly impossible. I don't have any idea how to do that! (Only commiting one big patch which does everything, and we definitely don't want that) > Unfortunately, I can't promise that I will be devoting a lot of time to > this, but I think I can help quite a bit with the specification/design > phase. As said these things will happen offline. We don't have the time to perform the task as an open process. We get marks for good quality source code and not for a long discussion ;) There will be of course also UML diagrams and alike. I will try to keep you up-to-date. > Good luck with your course, Markus. thank you mfg Markus ------------------------------------------------------------------------- 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
