[unct-devel] new developer and request for comments

[kris m <kr...@ev...>]

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/