|
From: Kris M. <Kri...@id...> - 2002-02-14 20:53:37
|
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] |