[unct-devel] Specification review

[Kris M. <Kri...@id...>]

I think it would be a good idea for all the members of UnCT to review the
specs, since we have a lot of new people who weren't around in the original
project (EATconf) when much of the discussion that formulated UnCT happened.
Also, after a lot of you joined up, things quieted down *very* quickly. The
combination of Bill losing his net connection for quite a while, and myself
moving and getting a new job sure didn't help matters. :-) But we're back
now, kicking and alive. :-) (That's a good thing, riiiight?)

Would everyone still interested developing/working otherwise for unct please
check in? Either by mailing to the list, myself, or Bill
(bi...@se...), or just show up on IRC sometime when
we're there. :-) (I won't be for next several hours, anyway.)

Anyway, below follows the original spec, with my notes. My notes are in
[]'s, and reflect my current views. I have not discussed them with anyone
else, and I don't know anything, so they may be blatantly wrong - they're,
for the most part, my OPINION. :-)

General 
	UCT will be coded in C. 
	  [ Clients in other languages are perfectly acceptable. ]
	  [ So are modules, so long as they conform to the correct
interface. Currently, a C module that loads a C++ class would be fine.]
	UCT will be implemented as a client and server. 
	UCT will be modular. 
	The client will implement a variety of interfaces. 
	  [ By this we mean Gtk/Console/KDE/... ] 
	The UCT server will send the client the information necessary to
draw its interface. 
	  [ But not nessecarily the *exact* way to draw it's interface -
probably just be an XML description of the data and the data. ] 
	UCT will be capable of maintaining an entire network of servers. 
	Client to server communication will be secure. 

Server 
  Will operate in three modes running as a daemon: 
	Stand-alone: The server is responsible solely for the machine it
runs on. 
	Master:The server is responsible for its own machine and other
servers. This allows UCT to manage a host of servers through one
interface. 
	Slave : The server takes its instructions from a Master server. 
	[Standalone: You ]
	[Master: Boss]
	[Slave: You responding to Boss]

  Will be modular : Most of the actual functionality of UCT will lie in the
modules that the server will load. For example there will be an 	"add
user" module for adding and editing users. This approach has several
advantages: 
	- It increases platform independence: Original development of UCT
will be done under Linux, but a concerted effort will be made 	 to use
fairly strict ANSI C and libraries which work on different UNIX platforms.
Developers will be able to write modules specific  	 to their platform
and they will work with UCT. 
	- Better end product : The development of UCT components will be
open to the community at large. This should make for a better 	 product
when all is said and done. If you don't like the "add user" plugin someone
has written, you can write a better one or 	 improve on the existing one
without having to rewrite the entire product. 

	[ also, I believe it is essential that the module Api is *extremely*
striaghtforward and easy to use. That way, when a developer writes a new
app, it will (hopefully) be a trivial job to also write a unct configuration
module for it. That's means our module API also needs to include functions
for reading/writing the most common configuration file-types (xml, ..., ini
type, others.), along with other data-access functions, i.e. mySql,
postgresql, and very excellent string handling/parsing capabilities, while
at the same time not intruding/fucking up the lower-level libc routines]

	The server will transmit the needed user interface data to the
client: Using XML, the server will transmit all of the data to the
client that the client will need to draw itself in a variety of ways and
communicate with the server. The client then processes 	user commands, does
some basic data validation, and sends the commands back to the server. The
server will first validate the 	client and make sure that they have
permission to do what they're attempting. Next, the server will pass that
information to a 	loadable module, which will do the actual work.
Finally, any information, error, or success codes will be transmitted to the
client. 

	[ bill & mike know more about xml than I do. :-) ] 

Client(s) 
	[ can't be done/started until we finish the communications protocol,
the xml that describes the UI, scomm, and other things. ] 

	The client will be able to express it's user interface via several
methods: 
	- Command line interface 
	  [ ... Going to be a pain in the ass to use, but would be nice when
no other way is available. i.e. 300 bps serial cable ]
	- Curses, console based interface 
	  [ I think Rob wanted to work on this. Rob, do you still want to? ]

	- GTK+/Gnome interface 
	- Web (CGI/FORMS/PHP?) interface?
	  [ I don't know ] 


--Kris


---
my personal address is [krism [a.t] evilpen d.o.t net]