|
From: kris m <kr...@ev...> - 2002-02-18 15:58:45
|
Hi Bill, Mike, and now, Oliver, Please welcome Oliver (opk @ sf.net) to the team. (opk, if you welcome yourself, please get a subscription to some anti-psychotics.) Below is a spec I did in the past half hour or so, loosely based on the previous unct spec, with bits and pieces added in from the freshmeat.net article mentioned. Please send all comments, arguments, etcetera, to the list. :-) So we can have an open-discussion. This is by no means "set in stone" - these are just ideas. (Most of them aren't even *my* ideas. :grin:) I'm hoping to return to the open discussion we had back when unct was EATconf. :-) Here goes. (PS. I left out all the stuff about GUI/xml-gui communications. I was feeling lazy, and I think those are kind of outdated, i.e. that there's a better way now. Also, opk brought up some good points about flaws in the client server architecture in UnCT. opk - should i forward your comments to the list, or can you?) Regards, Kris ideas: - client/server/master architecture as described in unct - modules provide specific functionality (i.e. user manager, etc) - that functionaility *can*, but is not *required* to be tied to module_api library, which: - provides the module_ff (file format) modules, that handle reading and writing different file formats (parsing is of course included in 'reading' :grin: ) /complex/xml /complex/m4 /simple/ini ... - /complex/gen_parser *could* be used as a generalized file parser; given an XML description of the data contained in the file, ... - if properly implemented/used, this would drastically reduce the required number of parser modules. - module_ff will not always be useful - consider /etc/hosts (bad example, i know, but..); would we write a parser for each of those or simply a configuration module? (of course, that configuration module could still make use of a generic type parser module - /complex/regex_reader; could read data from the file into variable 'x' until delimiter 'y', etc) - communications library will shelter the clients & daemon from any/all communications specific stuff: - for example, intent is to implement sockets, ssl, & ssh tunneling to start; these will all be transparent at the API level - do we want to keep the cron type stuff? - installation routine shall confirm to the LSB standards - UnCT core is in C; clients can use any language; mod_api will have multiple interfaces - previously, i don't believe we were thinking about handling files ~/. (i wasn't, anyway. :grin: ) i think we should handle them. :-) (ie. ~/.gaimrc, ~/.gnome/...) - some inordinatly strong version checking needs done at the module level. (not part of the spec, but of note.) i think it should be part of mod_api to indiscriminatly determine version numbers. (let me clarify that - from installed, binary programs; we can't do much without that. basically just parse appname --version, failing that, ... i dunno. :grin:) - we don't a module borking up an older version of application 'xxxx' with a configuration it doesn't understand ref: http://freshmeat.net/articles/view/400/ |