Server Skeleton

  As u all knoww, I've started to construct a server skeleton.  It's not based on the structure I published earlier, I hope to cover the structure here.
 Also this message deals with problems I have in the programming area, I'd like to
 recieve suggestions BEFORE I get to them. ( Justin that's ESPECIALLY for you )

1. Server structure:
2. The server is multi-threaded, by a User thread that handles the users requests
3. A machinePool class is responible for interpreting & forwarding information as for multi-server config, It's also responsible for connectiong / discon. servers.
4. 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. )
5. 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 ) ). Justin: I'l try to include parameter type info, we'l need to give another types, eg somethin like: t_Dir, t_YesNo, t_serverType and so on...
   • But!!!! ******* I want to make the parser universial, eg it ONLY loads the directives to mem and NOT further. I wan't to leave that to thhhe applet, to increase flexibility ( U get what I mean? ). I'l again describe my mission on the Server more clearly:
6. Directive Parser
7. addParam, getParam, setParam, addDirective, getDirective, remDirective, saveConfig, bootMachine, more.. on each level: User -> MachinePool -> Machine.
8. User interface ( I hope that's not SNMP! ;) ) ( Closed brackets? So, I'm a C programmer! );
9. Establish multi-machine communications
10. Password auth. and locks p.s. Locks I believe should be on a per file basis, cause some directives depend on other, like dir maps and file types, and an unplanned modification of one may be harmful.(eg. while another, the one it depends on, is also modified ).
    • For a while thou u all kept radio (e-mail) silence - why?

      ---

      Regards all, Roman Baron alphax1@ibm.net