You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(3) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
(15) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Cam <ca...@me...> - 2002-02-22 11:25:07
|
Sorry for the cross-post. I have just seen a writeup for GConf featured in Gnome 2. It sounds like it does everything I'd want so far. What do you think? Time for a rethink! http://developer.gnome.org/feature/archive/gconf/gconf.html -Cam -- ca...@me... <-- |
From: <ok...@ya...> - 2002-02-20 15:21:19
|
It seems that as a result of the freshmeat.net article, a mailing list has been set up. To subscribe, send a message to Maj...@ac... containing the words `subscribe dawn' in the message body. Oliver __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com |
From: kris m <kr...@ev...> - 2002-02-19 14:09:31
|
Some things I forgot to mention in my last email: The command line functionality "lusted" :grin: by Oliver could easily be accomplished by a command line client (assuming we stick to the client/server architecture.) Then the user would still easily be able to see what was happening. Yeah, instead of GUI clients or whatever just directly executing (and thusly hiding what they're doing) the commands, they could just shell (and log the i/o) of the command line client. Also, since commlib will handle all aspects of communication (including reading the users preferred method, i.e. sockets, ssh tunnelling, etc.), the rest of the config tool can pretend it's always fully authenticated. *Another communications module has been added to the spec, and it will be the first one done - loopback interface. ;-) Ultra secure, grin. No remote possibilty of data coming/going from anywhere but the local PC. --Kris |
From: kris m <kr...@ev...> - 2002-02-19 13:46:40
|
> I suggested before that I think the config file modifying program > should be a separate program[1] which can be invoked from the > command-line instead. If we have this, then rsh and ssh would be plenty > good enough for connecting to a remote host to run commands. This makes > things much more simple and easy and secure. It works well for CVS. And > we don't have to reinvent half of ssh and link against SSL, PAM etc. It > is sticking to the UNIX philosophy of doing one thing only but doing it > well. I totally agree that we should only do one thing, and obviously do it well. At the bottom of this message, I've inlined [2] a basic spec for the communications library, as it is currently proposed. Doing it in this manner reduces our need to reinvent the wheel - we can easily tunnel through SSH; if a module wants to link with SSL or PAM, it's more than welcome to. To summarize: the daemons and clients are completely shelterd from the actual details of communications by 'commlib'; commlib generalizes i/o to the point that the modules can handle the actual hard details. For starters, there is of course, a (non-blocking [1]) sockets module planned. > If you imagine an action such as changing a user (such as with > usermod), it would be useful to bring up on screen the user's current > details when prompting the user for new details. Also, for some of the > fields such as group membership, we would want to provide a list of all > possible groups. When making a change across multiple hosts, you would > have to contend with this information being different on different > machines. It'd make things simpler to just take the information from a > single machine (by default the local one). If applying the change on a > remote host produces an error, then we have to display the error (shell > scripts should be run with the -e (exit on error) option). Of course, modules could be flagged as 'safe' for master/slave execution. In the case of a user manager, it's simply not sensical to allow this ability. (Personally, I can't think of a case where it's possible usefullness outweighs it's possible security risk. If you can, *post to the list*. :grin: ) > [1] as an initial rough design for this program, it could have modules > for various generic config file styles (such as .ini (e.g smb.conf), > .xml, fixed character separated lists (e.g. /etc/passwd), assignment > lists (e.g. wgetrc)). The modules would provide an abstract interface > to the config file format mapping them into an XML like structure. We > could then use something like XSLT matching syntax to specify the > changes. So for smb.conf, you might match the [global] section, select > the workgroup key and change it's value. Everything else gets copied > as-is. For programs with simple config files, we'll perhaps be able to > use sed or awk instead of the new command. Initially, it might be > better to stick to existing UNIX commands and come to this when we need > it. We're having a 'nomenclature-clash'; laugh; when I say modules, I mean loadable units of code. While I admire the the layout you envision.. For example, the actual configuration tool then needs to handle parsing, reading and writing of these files /etc/passwd, and it becomes very platform dependent on the format of them. (i.e. RedHat 7.2 using /etc/X11/... and BSD 4.5 using /etc/XF86Config... no, it's *not* just the X versioning issue.) Also, if the modules were just .xml files, they couldn't handle advanced creation of configurations; imagine a module that configures XFree86. > To outline my ideas for the main config tool: There would be a > directory structure containing .xml files. So this directory might > contain a Networking directory which might include dns.xml routing.xml > ppp.xml bind.xml. The directory structure could be more than one level > deep. Individual directories and files here could be removed or added. > Symbolic links could be used so that for example, NFS configuration > might be under both networking and file systems. And as I suggested > before an environment variable would list directories to search for > these files. I like and agree with the directory layout; it could be done similarly for loadable modules. > Individual .xml files would look a bit like an HTML form but more > complex. An input field might specify a shell script which if run would > generate a list of possible values. So if you want to delete a print > queue, it could generate a list of print queues to prompt you with. > When you submit changes, it would again have a shell script to run. m4 > preprocessing this shell script would make it possible to make the > script minimal and to insert the user-entered values into the script. See Bill's mod_api initial spec also inlined [3] below. > You may have already decided on this but I would suggest that > everything supports unicode from day one. Unfortunately, I don't know > much about it. Since we're starting a clean code base, and *you* suggested it, .. grin, I have no problem with it, and it's a really good idea. Who wants figure it out? I'll play with it if I get time later today. > I'm not too sure that I like the program's name. I tend to prefer > natural language words (not necessarily English) to vowel-less > acronyms. Another suggestion is that the project is moved from > Sourceforge to GNU's Savannah. I'm not 100% happy with the new > Sourceforge terms. It'd give us a higher profile with the FSF and > improve chances of becoming official GNU. Being officially part of GNU > would help a lot in making the project successful (plenty of GNU > projects do better than superior alternatives). As for the name, we were short on time. :-) I'll check out Savannah today, any thing other than sf.net I'm likely to be happy with. ;-) (Ask bill, i've been bitching about it since day one :wink:) [1] non blocking because it just doesn't make sense to block; other communications means might not block (imagine reading from a script file as a communication means...); in the proposed spec, the command structure would report a value similar to "no data ready" [2] COMMUNICATIONS API <kr...@ev...> ------------------------------------------- - Things that need the ability to communicate - client & server - server::master & server::slave - Provides C and C++ interfaces. "Transport"* layers are provided by loadable modules. - Commlib will initially include transport layers for sockets, sockets tunneled via SSH, and IPC. More to come later, including SSL. - commlib will read it's configuration (in the server context that is) and allow/disallow connections at that level; it takes the responsbility away from the server/client, and disables an errant client/server from accidentally getting permission. - commlib will ABSOLUTELY NEVER BLOCK. * In this context, meaning such as sockets, ssh tunnelling, serial line, ... API: // general int comm_query_transport_types((void* callback_fnc)(char *name, struct_describe)); // struct_describe contains detailed information // on that transport layer; presentation name, // version, ... etc // client side int comm_open_connection("hostname"); comm_read_command(con,&cmd); // command structure - will not block comm_send_command(con,&cmd); // has an int specifiying the type of command comm_close_connection(int con); // server side int comm_server_startup("hostname"); // interface to accept connections on; NULL for lo int comm_accept_connection(); // accepts the current incoming connection // never blocks; int comm_close_connection(int conn); // [3] mod_api spec: Hrmm... well the basic idea is this: -Each module gets "registered" with the server. -Each function that you will want to be able to execute from the client also gets "regitered". That way, when you need to kick off a function on the server from the client, it sends the module name, function name, and function arguments over the wire. A service in the server will take this information, look up the correct function, and kick it off with the arguments. For now, the "arguments" will be a null terminated char*, and the function will need to "decode" this into individual arguments. Here's some ideas for solutions to this: 1. Each registered function will have a "helper" function which decodes the arguments and passes back the proper data types. 2. The client passes the data in xml format, which the server decodes, thus passing the function the proper arguments... here's an example: ---Begin data coming in from the client--- <execute mod="user_config" function="add_user"> <uint32>502</uint32> <char_ptr>bill</char_ptr> <char_ptr>/home/bill</char_ptr> <uint32>502</uint32> <uint32>100</uint32> </execute> ---End data coming in from the client--- The server would get this, cast the various types, lookup the module and function, and then call the function something like this: t_module *module; t_function *function; uint32 arg1, arg4, arg5; char *arg2, *arg3; module=module_lookup(master_mod_list, "user_config"); function=function_lookup(module, "add_user"); arg1=cast_uint32(args, 1); arg2=cast_char_ptr(args, 2); arg3=cast_char_ptr(args, 3); arg4=cast_uint32(args, 4); arg5=cast_uint32(args, 5); *(function)(arg1, arg2, arg3, arg4, arg5); |
From: <ok...@ya...> - 2002-02-19 12:55:22
|
I've thought a little about this suggested feature of being able to make a change across multiple hosts and decided how I think it would perhaps be best achieved. I suggested before that I think the config file modifying program should be a separate program[1] which can be invoked from the command-line instead. If we have this, then rsh and ssh would be plenty good enough for connecting to a remote host to run commands. This makes things much more simple and easy and secure. It works well for CVS. And we don't have to reinvent half of ssh and link against SSL, PAM etc. It is sticking to the UNIX philosophy of doing one thing only but doing it well. If you imagine an action such as changing a user (such as with usermod), it would be useful to bring up on screen the user's current details when prompting the user for new details. Also, for some of the fields such as group membership, we would want to provide a list of all possible groups. When making a change across multiple hosts, you would have to contend with this information being different on different machines. It'd make things simpler to just take the information from a single machine (by default the local one). If applying the change on a remote host produces an error, then we have to display the error (shell scripts should be run with the -e (exit on error) option). [1] as an initial rough design for this program, it could have modules for various generic config file styles (such as .ini (e.g smb.conf), .xml, fixed character separated lists (e.g. /etc/passwd), assignment lists (e.g. wgetrc)). The modules would provide an abstract interface to the config file format mapping them into an XML like structure. We could then use something like XSLT matching syntax to specify the changes. So for smb.conf, you might match the [global] section, select the workgroup key and change it's value. Everything else gets copied as-is. For programs with simple config files, we'll perhaps be able to use sed or awk instead of the new command. Initially, it might be better to stick to existing UNIX commands and come to this when we need it. To outline my ideas for the main config tool: There would be a directory structure containing .xml files. So this directory might contain a Networking directory which might include dns.xml routing.xml ppp.xml bind.xml. The directory structure could be more than one level deep. Individual directories and files here could be removed or added. Symbolic links could be used so that for example, NFS configuration might be under both networking and file systems. And as I suggested before an environment variable would list directories to search for these files. Individual .xml files would look a bit like an HTML form but more complex. An input field might specify a shell script which if run would generate a list of possible values. So if you want to delete a print queue, it could generate a list of print queues to prompt you with. When you submit changes, it would again have a shell script to run. m4 preprocessing this shell script would make it possible to make the script minimal and to insert the user-entered values into the script. The distribution could contain a set of these xml files which would be combined with information gleaned from autoconf, and processed with XSLT to produce more platform specific xml files. If the project is successful, applications could distribute their own xml files. You may have already decided on this but I would suggest that everything supports unicode from day one. Unfortunately, I don't know much about it. I'm not too sure that I like the program's name. I tend to prefer natural language words (not necessarily English) to vowel-less acronyms. Another suggestion is that the project is moved from Sourceforge to GNU's Savannah. I'm not 100% happy with the new Sourceforge terms. It'd give us a higher profile with the FSF and improve chances of becoming official GNU. Being officially part of GNU would help a lot in making the project successful (plenty of GNU projects do better than superior alternatives). Oliver __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com |
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 > |
From: <ok...@ya...> - 2002-02-18 17:38:59
|
Sorry, this is a bit quick because I have to catch a train. In two weeks I should have more time than I do at the moment. --- kris m <kr...@ev...> wrote: > Yes, we already agreed on the GPL. Though if you have anything which other programs may want to link against, those parts may need to be LGPL. > So, you mean "just use the loopback interface" by default? Make the My knowledge of sockets is a bit out of date but from what I remember, you could open different types. Those which are local and those which go over the network. > entirely sure what you mean by "interface module" - I think you mean > in > the same fashion that what we're calling the "console client" is an > interface module. Is that what you mean? I have absolutely no problem Its a slightly different to above but we could have the server daemon as a interface module like console/gui clients. > Hrm, I'm not sure I quite understand what you mean by "different > areas." > Can you give a small example of the XML file you're envisioning? Well a samba.xml or dhcp.xml might be a single area. Directories at the higher level would describe things like "Security and Users", "Network", "Applications". samba.xml would describe all the things which can be done to configure samba. > > search for the XML descriptions in these directories. > I think our "shared vision" is a bit skewered. What's contained in > those > directories? Similar to /etc, or? The xml files I was talking about above. I fear that the changing multiple hosts together may be troublesome because they might have different initial configurations. Oliver __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com |
From: kris m <kr...@ev...> - 2002-02-18 16:47:36
|
On Mon, 18 Feb 2002, Oliver Kiddle wrote: > Can I suggest using autoproject to start the new code base. That way > you get a skeleton for the command-line parsing and a GNU style layout. Suuuuuuure. :-) I'll read up on it and try to do it over my lunch break. > Is the work going to be GPL? Yes, we already agreed on the GPL. > Can I suggest that we e-mail everyone who wrote an > intelligent/enthusiastic comment on freshmeat or slashdot and try to > bring all the discussion to one single place - whether or not that is > here. I like how you specify intelligent and/or enthusiastic. :-) That sure sounds like a good idea to me, although we should perhaps organize that somehow(?). Anyway, .. yeah, let's do it. > I'd still have my reservations about this. Minimising valunerability to > security problems being a biggy. I'd suggest that the network server > just be an interface module that by default you wouldn't use. It could > then securely use sockets internally for communication between > interface and the main program. So, you mean "just use the loopback interface" by default? Make the user actually have to *turn on* the ability to be controlled by an outside IP? What?! That might make the system secure!! :grin: Of course, I'm not entirely sure what you mean by "interface module" - I think you mean in the same fashion that what we're calling the "console client" is an interface module. Is that what you mean? I have absolutely no problem with making it difficult for the user to hurt themselves, as long as we don't lose functionality originally decided upon. :-) (eg - the example of a network wide change was one of the original reasons for starting the project.) > At the very least the Linuxconf error of keeping it's own record of > configuration must not be repeated. Where possible, we should use > existing commands such as useradd, chkconfig etc instead of changing > config files. It should be possible to see the list of commands being > run like in AIX's smitty. I'd be tempted to wrap up the config file > changing into a separate command which can be invoked from the command > like. Absolutely. Positively. I totally agree. AFAIC (care), the daemon doesn't need to give a rats ass about the system config, and could easily shell to another executable to make the actual changes. (Yet Another Layer Of Security... Yay! :-) > I'm not sure about that. I'd use separate XML files to describe > different areas to configure. The XML would describe enough to do the > configuration. I'd embed m4 preprocessed shell code for as many of the > actions as possible and for getting lists of possible options. This way > people can see what the program is doing rather than Linuxconf style > hiding. Hrm, I'm not sure I quite understand what you mean by "different areas." Can you give a small example of the XML file you're envisioning? > People should be able to get the program to configure their application > by merely installing an XML file in the appropriate place assuming > their config file is generic enough or they have a command which can do > the configuration. This means that people will not have to navigate > menus full of configuration for components they don't have. I'd use the > directory structure to create a hierarchy of menu options (which the > GUI interface may represent as a collapsible tree). This is similar to what we were intending with the modules. The client would only report the modules installed on the daemon. (And because you connected to the daemon via sockets, you could (assuming authentication) very easily configure a remote machine.) Of course, .. X kind of moots this issue, as does any kind of connection to the remote machine. > This is why I'd put the config file altering in a separate command - it > could be invoked directly from cron. Cool idea, but not what I meant - Bill made a version of cron inside the daemon (err, a scheduler, simply runs command at time.) > If everything is described in XML files, we could have a CONFIGPATH > variable defaulting to ~/share/config:$prefix/share/config. It would > search for the XML descriptions in these directories. I think our "shared vision" is a bit skewered. What's contained in those directories? Similar to /etc, or? > it would be better to keep interface modules part of the same package, > at least initially so that versioning isn't an issue. I had meant to determine version numbers of the application that they're trying to configure; but if we shy away from the modules approach, .. this doesn't matter. > I'd suggest using libxml2. It looks good and the author was very > responsive when I e-mailed him a year ago. We already do. :-) --Kris |
From: Bill R. <bi...@se...> - 2002-02-18 16:42:46
|
Hey Kris & UnCt people, OK, Here's some notes I wrote up on Kris's ideas, the freshmeat article, and some of my own ideas. Nothing too cohesive, just some things I'm throwing out there to stir up some thoughts. +mod_api: We will need something like this for all of the modules. Its basic purpose will be this: Programatically, we will be getting a char* over a socket from the client, and with this information we will need to kick off a process on the server. When we "register" a module, and a function in a module, it will take a function that say, adds a user, and give it a name like "add_user". The char* from the client will adhere to some standard we set, and contain the name of the function to kick off ("add_user"). Then we know what function to start. The char* will also contain the information to provide as an argument to the function. +file formats: I agree with Oliver that we should keep all *new* configuration files in XML. That way it's all in one format, and XML really isn't very hard to grasp. We don't want everyone who writes a module to be using their own, different format. Obviously, we would leave any existing configuration files alone. BTW Oliver, we've been using libxml2, and it is a very nice API. +revision control: Someone bought this up in response to the freshmeat article. This sounds like a good idea. Every time a configuration file is changed, a copy of its last state is kept with some sort of revision control. This could also be applied to system wide configuration files that are changed as a result of UnCt's actions. +cron: We probably want to keep this. This would be useful for admins. You could set x,y, and z commands to be kicked off whenever you want. This is more of a system administration tool than a configuration tool, but very handy, and already implemented, so I say we keep it in. Bill |
From: <ok...@ya...> - 2002-02-18 16:18:33
|
--- kris m <kr...@ev...> wrote: > By rebirth, I had meant with a *clean* code base - the old code still > exists, but starting over (for the most part). Can I suggest using autoproject to start the new code base. That way you get a skeleton for the command-line parsing and a GNU style layout. Is the work going to be GPL? Can I suggest that we e-mail everyone who wrote an intelligent/enthusiastic comment on freshmeat or slashdot and try to bring all the discussion to one single place - whether or not that is here. > At the bottom of this message is the "spec" - I'm literally working > on it > right now, so... Ill have a look. > Client/server architecture; the reasoning behind this is the intent > to > make it simple make massive, network wide changes - i.e. if all the > computers in your business are running the daemon, you can connect to > a > master daemon, issue a command to switch over to DHCP issued IP's, > and > *poof*. I'd still have my reservations about this. Minimising valunerability to security problems being a biggy. I'd suggest that the network server just be an interface module that by default you wouldn't use. It could then securely use sockets internally for communication between interface and the main program. At the very least the Linuxconf error of keeping it's own record of configuration must not be repeated. Where possible, we should use existing commands such as useradd, chkconfig etc instead of changing config files. It should be possible to see the list of commands being run like in AIX's smitty. I'd be tempted to wrap up the config file changing into a separate command which can be invoked from the command like. > - client/server/master architecture as described in unct > - modules provide specific functionality (i.e. user manager, etc) I'm not sure about that. I'd use separate XML files to describe different areas to configure. The XML would describe enough to do the configuration. I'd embed m4 preprocessed shell code for as many of the actions as possible and for getting lists of possible options. This way people can see what the program is doing rather than Linuxconf style hiding. People should be able to get the program to configure their application by merely installing an XML file in the appropriate place assuming their config file is generic enough or they have a command which can do the configuration. This means that people will not have to navigate menus full of configuration for components they don't have. I'd use the directory structure to create a hierarchy of menu options (which the GUI interface may represent as a collapsible tree). > - do we want to keep the cron type stuff? This is why I'd put the config file altering in a separate command - it could be invoked directly from cron. > - 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/...) If everything is described in XML files, we could have a CONFIGPATH variable defaulting to ~/share/config:$prefix/share/config. It would search for the XML descriptions in these directories. > 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, it would be better to keep interface modules part of the same package, at least initially so that versioning isn't an issue. I'd suggest using libxml2. It looks good and the author was very responsive when I e-mailed him a year ago. Oliver __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com |
From: kris m <kr...@ev...> - 2002-02-18 15:58:45
|
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/ |
From: kris m <kr...@ev...> - 2002-02-18 13:14:22
|
I wrote Bill earlier this morning fearing I had borked the 'config' repository in CVS, but - no fear, I just got it out of CVS, and it's OK. (However, it didn't compile for me, but I'll look into that later, laugh.. :-P at work right now.. sigh) --Kris |
From: Kris M. <Kri...@id...> - 2002-02-15 20:34:30
|
Notes: 1. ppl unregistered the channel on openprojects. I'll reregister it tonight. 2. Useless (i.e. inactive) members have been removed from the project 3. Mail-list settings have changed - subscribed billr's current address, and you must be a member to post Odda Stuff: 1. Do we want to re-start with a "clean" (i.e.) empty codebase? I'm (obviously) partial to this. 2. Bill - can you post a (a least a pre-alpha) sample of the XML (even if you just make it up off the top of your head :grin:) that modules will use to describe their U/I to the client? 3. We need to cement down a module api. Fast. Wanna do this Bill? 4. We need to cement down a client/server protcol. Not to mention a communications library, be it scomm or some other incarnation. I'll do this if you don't care. :-) (i.e. both client/server) Anyway, just a start.. I think we need to set up some kind of automated testing procedure. I'm playing around with lint, I'll post something to the list when I know more. Kris --- my personal address is [krism [a.t] evilpen d.o.t net] |
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] |
From: Kris M. <Kri...@id...> - 2002-02-14 20:14:10
|
(no, we're not dead yet.) Was just browsing Bill's module_api stuff.. :-) Nice. Does this interoperate with the stuff I currently have in the daemon for module loading/basic interrogation? (Information retrieval, I mean, i.e. authors name, etc) Or do we want to eliminate/completely change that code? I think we probably should; when I wrote that code, it was really just a test. Mostly "hey, will this work," and it did, so I left it alone. Perhaps we need an open discussion on this list about the module API? (At least to get it through my bloody thick head.) I'll do my damndest to finish up scomm2 tonight. (Will take negligible time, it mostly depends on if sendmail & I stop fighting. :grin:) Also, for an easier method of contacting me - my AIM id is "negacao" and "negacaoWork" (usually 8a - 6p or so, EST). Paul created a channel for us on irc.openprojects.com #unct. :-) Thanks Paul. --Kris --- my personal address is [krism [a.t] evilpen d.o.t net] |
From: Bill R. <bi...@tr...> - 2001-12-11 03:37:49
|
Hey fellow unct people, It's time to get moving again. We've got unct to the point where we have some working parts, but it doesn't really *do* anything. It's about time to make it do something. Here's the plan. We get the scommm code reworked, and get the module APIs flushed out, and write a working module. We've got bits and pieces of all of these things now, but they don't form a coherent whole. Kris & I figure that he & Rob & Piere-Paul can go to work on scomm, and Mike, Simon, Rex & I can get going on the module API and a real working module. We want to be done all of this by Feb 10th. And comments/suggestions are much appreciated. Let everyone know what you think. Bill |
From: Kris M. <mat...@ya...> - 2001-11-25 23:26:35
|
Howdy, Just wanted to let everyone know; I'm changing my ID on = sourceforge.net from 'torch11' to 'negacao.'=20 Having troubles with torch11 account, this just seems the easier = route. So, no, there's no one new on the project. Just me killing an old = account... --Kris |
From: Kris M. <mat...@ya...> - 2001-11-12 23:29:36
|
Okay, now the list should be functional! Finally, rofl.=20 Everyone on the list? Please acknowledge: mat...@ya...=20 Thanks, Kris |
From: Kris M. <mat...@ya...> - 2001-11-12 14:14:37
|
Howdy All, First note: Please welcome Rob Meyers to the development team. He'll be working (for the most part) on the client. He really knows his stuff, so I believe we'll be seeing nice code from him. :-) Note number two: Sourceforge.net is finally resetting the mailing list password within the next 24-48 hours, which means slklein and ppl will be able to subscribe to unct-devel, finally. :-) Also, Rob, you may want to subscribe to the mailing list 'unct-devel' from our project page at sourceforge.net. Oh yeah, (sigh) scomm is likely getting a re-write.. --Kris |
From: Kris M. <mat...@ya...> - 2001-10-27 02:48:26
|
Yay, Scomm now has proper timeouts functioning, and a severe bug was fixed a week or so ago. How's it going, all? --Kris ---- .sig: don't tempt me, or i'll B4 4C CD 21 you. http://slashdot.org/ |
From: Kris M. <mat...@ya...> - 2001-10-11 00:50:02
|
AAAAAAAGH! This is starting to get annoying.... Sigh, I cannot remember my password to the mailing list! Anyone have advice how to add slklein to the list w/o waiting for the mailman to mail me my "monthly" password reminder? --Kris ---- .sig: don't tempt me, or i'll B4 4C CD 21 you. http://slashdot.org/ -----Original Message----- From: unc...@li... [mailto:unc...@li...]On Behalf Of unc...@li... Sent: Wednesday, October 10, 2001 5:13 PM To: unc...@li... Subject: 1 Unct-devel admin request(s) waiting The Unc...@li... mailing list has 1 request(s) waiting for your consideration at: https://lists.sourceforge.net/lists/admindb/unct-devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: sl...@ti... on Wed Oct 10 11:06:15 2001 Cause: Message may contain administrivia |
From: Kris M. <mat...@ya...> - 2001-10-09 12:24:13
|
Howdy All, Anyone else having a bug with the daemon crashing becoming unresponsive? It'll only happen occasionally, i.e. you'll start the daemon up, everything appears to be OK, but the client hangs on connect.. If anyone else is able to replicate this problem, please send log files, advice, etc, to the list.. :-) --Kris |