Re: [unct-devel] new developer and request for comments

[Michael A. R. <mro...@ho...>]

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
>