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.
