I divided up my interface slightly differently. Basically, I kept track of administration tasks we've had to do most often and then both moved these common admin tasks to the "front" of the interface and also grouped functions which tend to be done together in the same dialogue. For instance, I grouped the stuff which must be done to first setup a server under "basics", things which involve the numeric setup of capabilities of the web server under "capacities", access controls and users under "security", etc.
Further, I didn't distinquish between virtual or real servers instead saying that some configuration items are 'global'- that is they apply to all servers while others are server, directory or file specific. The configuration not based on the concept of editing files but instead on the configuration of a specific server (virtual or otherwise). Thus once you've selected a machine, then you are presented with all the servers available on that machine and then shown the current directives and values associated with that server whether they are setup especially within that server or have flowed down from global settings. I'm working on a description of internal data structures that accomplishes this- with locks and all. The assumption I'm also making is that the data structure will be populated by a separate method allowing the server to operate on the data structure to configure the server and then just make a call to read/write/update the information in a format that the actual Apache server can use (flat files or whatever). This allows up to easily change the method of storing config file and also to configure multiple servers simultaneously (via judicious locking of the data structure). Justin [EMAIL PROTECTED]
