Re: Protocols and Plans

[Maj Justin Seiferth <se...@www.disa.mil>]

>   We first have to choose wether the applet send commands which are
> proccesed by the server to directives or the applet will make the figure-out itself.
>    If so, additional services will simply be configured by another
> applet ( like a plug-in )and the services writer (if it's not Apache group) could use the GUI
> advantages without the need of telling us to recompile and re-distribute the new Conf.
> server.
>
My idea would be that the client would send (via whatever protocol) the
action, directive name and optionally the value of the directive to the
server.  The action would be SET or GET (per the ramblings paper), the
environment, the directive would be a verbatim string and the value
would be a list of strings.  For instance to set the server type you
might send:

SET GLOBAL ServerType Standalone

It would be up to the server to parse this and verify that:

   * the environment (global or a specific server such as www.disa.mil)
     exists
   * the directive exists (send an asychronous error message back if it
     doesn't)
   * the value being set is appropriate (also send error back if SET
     GLOBAL ServerType  116.117 was sent as a message to the server.) In
     this case only the values "standalone" and "inetd" would be
     acceptable.
   * this is either a new directive (in which case it must be inserted
     into the proper file) or that it is a change to an existing
     directive whose value must be updated.

This message would be captured, parsed and handled by an event loop. The
error checking has to be done on the server end to accomodate people
sending scripted commands to it.  We might assume that the GUI would
always send correctly configured commands but we can't make the same
assumption about scripts.

I don't see any easy way around recompilation of the server and client
GUI to accomodate new core directives.  This is because not only may the
format of the directives change but also their importance in the
hierarchy (for instance, only certain directives may appear in an
.htaccess file or within <DIRECTORY> tags).  Perhaps there's an elegant
way to capture this information in an elegant text-based configuration
file but it's not readily apparent to me.  The handling of modules is a
little different, this should be able to be done on the fly by having a
module specific class built and it's methods called when the module is
included in the server (either through a dynamic library aka "DLL" in
microsoft speak or by inclusion in a static compilation).

 If we specify a standard template class for modules authors of modules
could include the configuration class or we could easily build them.
The class would just have to say what directives were legal, type valid
value types for the directive (eg IP address, binary switch, integer,
etc) and within what context (eg .htaccess, etc).  Now that I'm thinking
about it this same idea could be extended to the core directives and to
some extent within the client as well.  I'm pretty certain that most
changes in directives and functionality will require a recompile of the
client and the server.  This isn't a biggie in my estimation though as
we only need to make one .class set for all platforms (gotta love java!)
and eventually the directives will settle down.  For all this discussion
I don't think there will be many changes except at major versions.

(Randy- what do you think of this idea? Also, Randy, can you accept HTML
format mail?).

>    Chatting is a little  hard to arrange, do u have IRC client? I'l be
> using irc.ibm.net.il as the IRC server. My nick is ussualy CyberGod,  or DiGiTaLNT and I'm
> connected about from 23.00 (evening)  to 02.00 or so. Israel is GMT +2.
>
 I'll find out if I have one; I'm sure there's one available I'll just
build it and try this stuff out.  I may try tonight or if not then when
I get back from the beach :) on Sunday.

Justin