The server structure

[Roman Baron <al...@ibm.net>]

    Hi all.
 I've just read Justin's DOC (or just as much as i could :)) on the
server's structure in detail. I've found something like blackspots (for
me etc.) so I'd give u my perspective
 on that:

 Please remember that it based on Serialization and that's not yet
decided to go,
 So, I'l change that part if neccesary.

  The Server

 The server is constructed with the next structure:


   *  Main class - Initializes all others, monitors for locks
        o     User thread - responsible to handle the users input (i/o)
        o     Machine class - will include all ConfFile classes in a
          hashtable
             +  Parser class - is responible for loading and saving
               files themselfs ( Includes Directive class)
             +  ConFile class - this includes all parameters of a config
               file such as lock, directives, etc.
                  + Directive class - this includes a single directive
                    and it's paramters

       Detailes

        o  The interface is handled by the User thread
        o  The locks are synchronize() based
        o  Locks are one per conf. file
        o  Interface uses Serialize to exchange Directive objects
        o  User thread includes (objects of) Machine
        o  Parser class will gennerate the ConFile objects
        o  Multiply users are allowed
        o  Multiply machines are allowed


      So what do u think? This way, all I have to do to change the
interface is Change some code at the user
  class, and it won't affect any others at all!

    We can always convert it with java2c to C code ( We should test if
serialize is supported by the outcomingg code )

   Let me know what u think, hope the background wasn't too big, Regards
all, Roman

Re: The server structure

[Roman Baron <al...@ibm.net>]

 Justin well I've chaged it for the better at the template :) more to
come!

  I'm gald someone is on the list!

Re: The server structure

[Brian Behlendorf <br...@organic.com>]

At 01:02 PM 8/26/97 -0400, Mark A. Imbriaco wrote:
>
>> This (confile) will have to be in sequential (line number) order and
>> there should be one instance per conf file.  The apache group is moving
>> towards storing everything in one (httpd.conf) file but most sites I
>> think still do it the old way (httpd.conf, srm.conf, access.conf).  I'm
>
>	Actually, it was my understanding (from lurking on the Apache
>	Group mailing list) that the move was not so much to a single
>	config file, but to an arbitrary number of config files, and
>	replacing both AccessConfig and ResourceConfig with a new
>	directive.  (ConfigFile was suggested..)  AccessConfig and
>	ResourceConfig will probably end up as synonyms to ConfigFile
>	for compatability's sake.

"Include".  It's been committed to the current CVS tree for 1.3.  

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Why not?" - TL           brian@organic.com - hyperreal.org - apache.org

Re: The server structure

["Mark A. Imbriaco" <ma...@itribe.net>]

> This (confile) will have to be in sequential (line number) order and
> there should be one instance per conf file.  The apache group is moving
> towards storing everything in one (httpd.conf) file but most sites I
> think still do it the old way (httpd.conf, srm.conf, access.conf).  I'm

	Actually, it was my understanding (from lurking on the Apache
	Group mailing list) that the move was not so much to a single
	config file, but to an arbitrary number of config files, and
	replacing both AccessConfig and ResourceConfig with a new
	directive.  (ConfigFile was suggested..)  AccessConfig and
	ResourceConfig will probably end up as synonyms to ConfigFile
	for compatability's sake.

	-Mark

Re: The server structure

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

My comments on your class layout.

> The Server
>
>  The server is constructed with the next structure:
>       Main class - Initializes all others, monitors for locks
>               User thread - responsible to handle the users input (i/o)
>               Machine class - will include all ConfFile classes in a hashtable
>                 Parser class - is responible for loading and saving files themselfs (
>                Includes Directive class)
>                 ConFile class - this includes all parameters of a config file such as
>                lock, directives, etc.
>
This (confile) will have to be in sequential (line number) order and
there should be one instance per conf file.  The apache group is moving
towards storing everything in one (httpd.conf) file but most sites I
think still do it the old way (httpd.conf, srm.conf, access.conf).  I'm
not sure that this class really needs to exist, it's just an ordered
list of instances of file directives.  We need to make sure (if this
file does exist) that it can for instance pull out all the directives
associated with a specific virtual server (to update them or eliminate
them if we're deleting a virtual server).

>                     Directive class - this includes a single directive and it's
>                     paramters
>
I think an instance should also contain what type of value is valid for
the directive (boolean, filepath, IP address, etc).  This will allow
some error checking.  I'd also recommend the use of a "meta-data"
pointer- this will allow the system to store some sort of help, for
instance what org or site an IP address in the access list is associated
with. The directive class should also maintain a "context" value- that
is what server/directory/file the instance is associated with.  This
will allow the manipulations I talked about in my comments to the
ConfFile class.

>        Detailes
>
>            The interface is handled by the User thread
>
Will there be a broker so we can isolate the communications code from
everything else?  I need to replicate this broker on the client.

>            The locks are synchronize() based
>
Physical locks on the files yes to prevent hand-editing of the files
while someone is using the config server. There also probably need to be
locks on individual instances of a directive.  This would allow someone
to manipulate, for instance, the access permissions of a particular
directory under the ServerRoot of a server without locking out someone
else from changing some other parameter of the server.

>            Locks are one per conf. file
>
See above

>            Interface uses Serialize to exchange Directive objects
>            User thread includes (objects of) Machine
>            Parser class will gennerate the ConFile objects
>            Multiply users are allowed
>            Multiply machines are allowed
>
Something to tackle later I think (the multiple machines thing).  The
multiple users requirement can be taken care of by the per-directive
locks.