www-gui-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Seiferth <seife...@erols.com>
Subject Re: Server Skeleton
Date Wed, 27 Aug 1997 19:35:31 GMT
Et al,


>      b. A machinePool class is responible for interpreting & forwarding
> information as for multi-server config, It's also responsible for
> connectiong / discon. servers.
>
I'd blow the multi-server functionality off for the moment.  If the
broker class I posted properly isolates the communications stuff and we
use a toolkit ala adventnet then we can tacklet this work at a latter
date- so let's ignore this for the moment (except for add the
appropriate fields to the directive class).


> c. A machine class is the one that handles the Directives
> hashtable, It's responible for loading it, as well as any other machine related stuff
(Remote
> server connections, etc. )
>
 Not sure what is meant by this.  There should only be a few directives
(like on the order of a few hundred at most )  the overhead of a hash
table probably isn't worth the increased search speed.


>  d. Directive class, is either going to be splitted or left alone (
> to Name & parametera) now that's an issue. We need either to make a Hashtable of
> Hashtables (Directives per group), or split the directive ( to (name, group) And to (
> parameters ) ).
>
 I think the class definition of Directive needs to contain:
    - int name (enumeration used to represent the name but save a tiny
bit of space. comments and
                        blank lines are also a form of directive in this
sense)
    - String value
    - int valueType  (enumerated to represent boolean, list of IPs or
whatever)
    - String context (see the multi-server discussion above.  Stores
machinename:servername:scope.)
    - int lock (I think this is necessary on a directive basis)
There should be an instance of Directive for each line of all the
configuration files.  The primary "view" of these directives is then the
line-number sequence in which they appear within the configuration file.
You can just store these instances in a linked list- nothing fancy.
Here's an example of an instance.

Head->LineOne                                        ->LineTwo
                - 0     // represents a blank line    - 3
// represents ServerType
                - null                                        - "inetd"
                - null  // means innapropriate        - 3
// means string
                - www.disa.mil:httpd:global                  -
www.disa.mil:httpd:global
                - 0     // don't need to lock this!    -
0                // not being edited

->LineThree                                            ->LineFour
                - 4    // <DIRECTORY>                    - 19        //
AuthType
                - "/usr/local/etc/httpd/test"                  -  "LDAP"

                - 5    // means valid directory path        - 20
// means one of basic, dbm, LDAP, etc
                - www.disa.mil:httpd:global                 -
www.disa.mil:httpd:global:/usr/local/etc/httpd/test
                - 1    // somebody is working here        - 1         //
locked because directory is locked


->etc.

Clear as mud?

The applet only sends directives back- it doesn't really evaluate them
other than to restrict (in the GUI) the available choices to valid ones
where it can. It has to be this way to support scripted (via PERL, TCL,
etc) batch uploads of configurations.  It's up to the server to really
check to make sure we don't for instance give an IP address as the value
of the ServerType directive.  This check is the purpose of the valueType
member. The GUI will of course ask for values when it needs to display
them.

Harrie, any ideas on how a mib set up to handle this type comm should be
set up?

Justin






--
Justin Seiferth




Mime
View raw message