I would like to see unified configuration accross all servers. Here is an excerpt from an old conversation between Chris Silverberg and I on this that I do not know if you ever saw:
>> From oleary Mon Dec 16 15:57:10 1996 >> From: oleary@svx001.lfwc.lockheed.com (Daniel Quinn O'Leary) >> Date: Mon, 16 Dec 1996 13:48:35 -0600 >> In-Reply-To: Chris Silverberg <chris@spiderisland.com> >> "Re: big difference" (Dec 16, 11:03am) >> References: <v03010d04aedb4c4ad395@[199.35.3.20]> >> To: Chris Silverberg <chris@spiderisland.com> >> Subject: Re: big difference > >On Dec 16, 11:03am, Chris Silverberg wrote: > >> Subject: Re: big difference >>DO> Jammin! Is 5 MB enough for now with the 168 K config file? >> >> Yea, it's plenty. >> >>DO> Also, if is not too hard, can you incorporate the comment feature like the >> DO> new config files? >> >> No, the comment feature is not really a feature. TeleFinder Server ignores >> comments when it reads the config files out. But when TF Server recreates >> the config file, comments will get lost! >> >> Rusty put those comments into the file just as a helper until we get the >> interface into TF Server so you do not need to edit the text files >> directly. When TF Server starts writing out config files, the commands >> will get lost. >> >> We afford to keep comments in memory. First, it uses up memory, second, >> when the file is rewritten, the order is determined by record type. As a >> result the comments would be written all in one block and out of order. >> >> >>DO> This will make it easier for me to document blocks of >>DO> the configuration file. >> >> I understand, but although these files are editable with a text editor, and >> we dont discourage that for people that know what they're doing, it REALLY >> IS a database file... and designed to be read in and written out by the >> application. >> >>-- End of excerpt from Chris Silverberg > > DO>In that case, I have some suggestions. I realize that these are probably too DO>difficult to implement now, but you can keep them in mind for the DO>future. DO> DO>If possible, merge all of the configuration files into one. This would DO>eliminate configuration errors caused by disagreements between information for DO>User Manager-Based Topic and File system Access Control, Realms-based Topic and DO>File system access control, Web Server URL Aliasing, and Mail Server topic DO>import/export. DO> DO>The file should have tokenized record types. A single byte could identify 256 DO>different record types. The file could be "packed", resulting in substantial DO>memory and on-disk file savings, as well as faster startup. DO> DO>Each server should read the file and only load records that are valid for its DO>operation. Records that are not valid for a particular server are ignored by DO>that server. DO> DO>When a modification is made to the database by any server, all servers should DO>be commanded to update their in-memory databases (via an AppleEvent originating DO>from the server making the change???). DO> DO>Whan a "Save" command is executed by any server, the contents of each server's DO>in-memory data base should be obtained and written to the file. Sequence of DO>this write is unimportant, since the record types are the mechanism for each DO>server to determine DO> DO>Each server should be capable of exporting (its portion of) the database to a DO>human-readable format upon command from a menu, and from an AppleEvent. DO>Translation of the tokens into human readable record identifiers should occur DO>during this process. This will: DO> DO>1. Make debugging of a large database easier by the administration. DO> DO>2. Provide an interface for processing of the database elements by external DO>programs. These programs could be used to extend the power of the existing DO>configuration by automating many processes that are now done manually. (Topic DO>thread location to topic link name assignment. Topic Link to Topic Set DO>assignment, UM Access Group to Realms control, etc could be streamlined using DO>templates and automation.) At the very least MS should be able to generate DO>updated NNTP Sucker "Groups" file and MK Areas.BBS files since these are DO>directly based upon the Topic names already within the configuration. DO> DO> DO> DO>Each server should be capable of importing (its portion of) the database from DO>a human-readable format. Translation of the human readable record identifiers DO>into tokens should occur during this process. This will make automated external DO>modifications of a large database easier. Applications of this would DO>be: DO> DO> 1. Automatic creation of the Mail Server, TF Server, and Web Server URL DO>Aliasing, and Realms changes when changes are made to NNTP sucker's Groups DO>File or MacKennel's Areas.BBS files by third party software that writes out the DO>ASCII version of the new configuration and commands the servers to update their DO>databases (using the same AppleEvent mention earlier). DO> DO. 2. Remote administration of global configuration by allowing the administrator to upload a DO>changed database file and restart all servers remotely. This would be very handy DO>for those sites that are not directly accessible by their admins due to co-location.
NNTP Sucker has been replaced by Lollipop for those running Open Transport, and there are still sites out there running gateway software. --- Daniel O'Leary, Admin/WebMaster KloneZone - A TeleFinder 5.7 BBS (817)367-2558 (Voice) (817)367-2712 (Dial-in) 1:130/1015 (Fido) klonezone.tfnet.org (TFNet) kz.eaze.net (Internet) http://kz.eaze.net (WWW)
