Am Freitag, 22. Dezember 2006 11:01 schrieb Chris: > On Thursday 21 December 2006 5:41 am, Avi Alkalay wrote: > > Lets put here some ideas we need for Elektra 1.0. > > Hi everyone, > > I've been casually following the Elektra project for some time, and > I'd like to make a major recommendation for your consideration before > pursuit of the 1.0 release.
I don't think that will go fast. > This is pretty large, but please > approach it with an open mind. I am open minded to even very far reaching changes. > Problem: Elektra currently has a very weak metadata. No, the metadata is fully equiped with relevant information, the only missing parts are Extended Attributes, but that could fit fine into its own hierachie next to a doc hierachie for describing the keys. > - Simplify the key API even further and move all metadata > functionality into a separate API. The metadata API is cleanly > separated and not required for the basic key-value system to > function. Yeah, there were some thoughts about that. We could use a libcomment parser for more metadata and a libvalue parser to be able to add ability of getting Integers and so on into the database in a common format. The main missing part is the contributer. > - Store (much richer) metadata in XML files throughout the > configuration hierarchy. Metadata is used for 3 basic purposes: > describing the schema, storing revision data, and storing advanced > permissions. Yeah sounds nice, but you can really use the comment field for that. And how can you archieve that it is possible to work without that lib? > - Manage those XML files with a metadata API and daemon. The daemon > may or may not have write access to anything but the metadata itself. > Alternatively, there may be multiple daemons for different purposes. This sounds like much overhead. However the metadata we have now in elektra is not just for fun. The security relies on it. You *really* need to know when it was accessed and who is allowed to do that. > - Build intelligence on top of the basic metadata API *g* Intelligence is not something you can just implement. You need a lot of knowledge how it should react. > This solution preserves the philosophies of simplicity and no single > points of failure. (If the XML metadata daemon dies, everything > still works.) Before I go any further, let me be perfectly clear > that I do NOT mean to store any key-value data itself in XML. > Everything else in the current Elektra spec can stay the same! I don't think that any changes are needed to archive that. Once someone comes with a good solution, we will certainly spend a own hierachy where the data can be stored. > > == Create an extensible type namespace == > > Types and their namespace should still defined by applications, rather > than Elektra having pre-defined types. However, defining them in XML > metadata would be far more flexible and expressive than the current, Applikations should not define there own types. Documents should explain how to do it right, so that all do it the same way, the intention of elektra. > address. With this ability, our higher-level admin tools can > validate input precisely and even provide rich data-input widgets in > a GUI environment. (Such as as a slider with values 1 to 100 or a > self validating field for an email address) Usable admin tools need to know the exact semantics of the keys. Of course it is desireable to be able to store such information in the comment field (or in your database). > - Store a complete revision history of key-values with timestamps, > usernames, tags, and comments. This also enables complete support > for versioning and rollbacks. Imagine if you could look at any given > key-value pair and see its history. Something like: I like these ideas, really. Of course it would be nice to have a revision control or distributed system integrated. But these features need to be on a higher level. Everybody is welcome to provide higher level features. > - Linking to documentation, templates, and examples. Imagine if your > Apache configuration was automatically hyper-linked to the original > documentation! Click on a directive and voila! There's all the > information you need! This would be a unix admin's dream come true. > Forget clumsy man pages and outdated dead-tree manuals! Thats the exact reason why we add a comment field :-) > Sorry that was rather long-winded. That's the basic idea. Let me > know what you think! I have many implementation detail ideas that > I'll save for a separate email later.. Really good ideas, I am awaiting implementations for that :-) 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
