|
From: Michael A. R. <mro...@ho...> - 2002-02-19 03:18:36
|
Hey All,
First up, welcome opk! Looks like there's finally something startin
'round here. Sorry for being out of touch, just completely bogged down
with work/life/stuff. Might be a little while before I get some real
time to pitch in, but it's getting closer. Great article Kris, I almost
made it through the comments :-) . Brings up some fundamental questions
on my part, but I'll have to ask them later (after I've read more).
Gotta go for now, I'll get back as soon as I can.
kris m wrote:
>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/
>
>
>
>
>
>_______________________________________________
>unct-devel mailing list
>unc...@li...
>https://lists.sourceforge.net/lists/listinfo/unct-devel
>
|