EchoList - The EchoMail Conference List Page 1 Technical Reference as of: 21 Feb 1993 ================================ The EchoList Technical Reference 21 Feb 1993 ================================ CONTENTS 1. PURPOSE..................................................... 2 2. ECHOMAIL DISTRIBUTION BACKBONES............................. 2 3. DEFINITIONS................................................. 3 4. HOW IT WORKS................................................ 3 5. ECHOLIST CONTENTS........................................... 4 6. RULES FILE REPOSITORY....................................... 4 7. SPECIAL DATABASE FIELDS..................................... 5 7.1. NODE ADDRESSES....................................... 5 7.2. NAME FIELDS.......................................... 5 7.3. KEY FIELD............................................ 5 8. UPDATE MESSAGES............................................. 6 8.1. TO ADD OR UPDATE AN ENTRY............................ 7 8.2. TO DELETE AN ENTRY................................... 7 8.3. TO ADD OR UPDATE A CONFERENCE RULES FILE............. 8 8.3.1. Rules File Attach............................. 8 8.3.2. Rules File in Message Text.................... 8 9. MESSAGE FORMATTING DETAILS.................................. 9 10. UPDATE MESSAGE FIELD DESCRIPTIONS........................... 9 11. PUBLICATION................................................. 13 12. ADVANCED TECHNICAL ISSUES................................... 14 12.1. DATABASE IMPLEMENTATION.............................. 14 12.2. KEY GENERATION....................................... 14 Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 2 Technical Reference as of: 21 Feb 1993 1. PURPOSE This document provides complete details on how to submit and maintain entries in the EchoList. For a quicker reference you can refer to the companion Users Guide. This Technical Reference is painfully long and boring. But that's the way it goes... The EchoList is a monthly publication which attempts to document certain interesting information about EchoMail Conferences; "interesting" to people who would like to participate, interesting to EchoMail Coordinators and those who route the conference traffic, and potentially interesting to the Conference Moderator. The base product of the EchoList database is the detailed Conference listing. But, as needs are identified which can be satisfied with the available information, additional reports and analyses can be developed. Basically, the EchoList is maintained by the Moderators who choose to advertise their conferences here. Additions and updates to the database are done by submitting NetMail messages addressed to a special name and node address. The Subject of the message indicates what is to be done, and the body of the message has the data for the database entry, formatted as one keyword and value per line. If you're familiar with AREAFIX or RAID message formatting, this will give you no trouble. Theoretically, updates should be sent by the conference Moderator. A password field is provided for the Moderator's use for controlling updates. As far as I'm concerned, anybody who can help with additional information (like seen-by's, paths...) is invited to do so. And, if future automated data gathering tools can be implemented, it will be encouraged. Of course, if the Moderator does not have the time to maintain the listing, a helpful associate could do it. Updates do not HAVE to be submitted by the Moderator, they just have to identify one. I created and maintain the EchoList as an advertising service for Moderators, and as a reference for users. It is a completely open, international and inter-network publication. I do not generate, nor do I normally censor the entries--they are the work of the Moderators. In kind, I also take no responsibility for the accuracy of any of the information in these entries. I am in no position to pass judgment on the validity of EchoList entries. It is strictly a first come, first served database. A final note on adding entries to EchoList. I will not list any conference which promotes illegal activities. Rejections based on unreasonableness will be solely at my discretion. The EchoList was originated by Thomas Kenny, and the bulk of the original design was initiated by Thomas, for which he has my thanks. 2. ECHOMAIL DISTRIBUTION BACKBONES A clarification is needed on the subject of EchoMail backbones and backbone conferences. The EchoList is not an official publication of any of the Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 3 Technical Reference as of: 21 Feb 1993 backbones, zones, networks or FidoNet. It is an open, free directory of information on ANY EchoMail conference, anywhere. However, a couple of distribution backbones have implemented a requirement (which I heartily endorse) that any conference they carry must have a Moderator identified. The Zone 1 EchoMail Coordinator (among others) has decided to use the EchoList as a convenient repository for official information on backbone conferences. So the only exception to the EchoList's voluntary status is that dictated by the distribution backbone you may choose to use. If you are using one of these backbones you must list, at a minimum, the Tag name, the Title, and the Moderators name and node number. I have no direct involvement in the distribution or administration of EchoMail itself. Any rules governing your conference need to be obtained from your network and/or distribution backbone. 3. DEFINITIONS I used-to provide lengthy definitions of Moderators and Coordinators, since I knew of no where else they were documented. This is no longer the case, since the backbones have published policy documents containing painstaking detail. I refer you to those documents. In the case of the EchoList, a Moderator is the person who defines a Conference, and keeps it on track. The Moderator may or may not be the originator of the conference. But he or she is assumed to be the one with authority over the internal operation of the conference, with the right to define it's purpose, policies and rules. If a conference has no Moderator it will not be listed in the EchoList. If more than one Moderator is listed for a conference entry in the EchoList, all are assumed equal in authority over that database entry. If you know of a conference which you feel is important to the community and it doesn't have a moderator I seriously suggest you consider taking on the job. How you do that, however, is business internal to the conference. 4. HOW IT WORKS If a Moderator wants to list a conference in the EchoList, he or she must send a message in the proper format (as defined below) to the EchoList update processor at 1:1/201. Since this is a completely automated procedure, the address name and node number must be exact in order to be picked-up. Update messages are processed at least once a day; I'm working on the performance so that they can be processed after every NetMail call. Every properly addressed update message will generate a reply message back to you via NetMail--even if the update failed. In addition, adds and updates of conference entries will be broadcast to interested EchoMail conferences (unless you tell ELISTUPD not to). In order to provide a level of reliability to the list, EchoList entries purge-off after six months. If you want to keep your entry active, you Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 4 Technical Reference as of: 21 Feb 1993 should re-send an update periodically (even if there are no changes) in order to refresh the list. The current purge criteria deletes EchoList entries with a last-modified date older than six months. The last-modified date is the date the message was received and processed. The EchoList is published on a monthly basis (around the first of each month) and purging is not done until the production date following the six-months anniversary. Updates to the EchoList are processed directly against the database, so there is no advance cut-off date for inclusion in a given edition. BUT, the EchoList is currently maintained as part of a hobby, so other time constraints will dictate how much can actually be accommodated in a given month and what the actual production date will be. It could be anywhere from the 25th through the 5th. I can only suggest that important changes be sent early in the month. 5. ECHOLIST CONTENTS The EchoList is maintained in an object-oriented database, which improves data management and reporting, and provides a great deal of flexibility concerning the contents of the database. But the update messages are processed by an automated front-end program which edits and processes them; and it is quite unforgiving. Computer programs are very literal cretins. The minimum information required for an EchoList entry includes: The symbolic area Tag name used by the conference, a Title or brief descriptive phrase for the conference, and at least one Moderator's name and node number. I understand that, for security reasons, certain Moderators do not want to publicize the Tag name in order to control unauthorized links to a private conference. The EchoList has the ability to suppress the display of the Tag name in the EchoList reports. However, the Tag name is the key to the database and all update processes. So even if you want it unpublished, it must be provided. In addition to the Tag name, the EchoList implements a derived Key field for each conference. You can ignore the existence of this internal Key in all but the most unusual situations. It is used to provide a unique, DOS file name compatible abbreviation of the Tag, and to allow multiple conferences with the same Tag (perhaps in different networks) to maintain independent EchoList entries. For those interested, there is a section devoted to the topic later in this document. If you feel there is a piece of information that is missing from this database but vital, please bring it to my attention. The best way to explain the various fields in the EchoList is to describe the format for submitting additions and updates. You'll find that in section 7. 6. RULES FILE REPOSITORY In addition to the EchoList itself, I provide a repository for text files documenting the rules for individual conferences. The rules files are Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 5 Technical Reference as of: 21 Feb 1993 tracked in the database, but are not reported as part of the EchoList. They are stored in a separate compressed file. Rules files have no purge criteria and do not have to be refreshed unless you change them. They will be valid as long as there is an EchoList entry for that conference. 7. SPECIAL DATABASE FIELDS 7.1. NODE ADDRESSES The EchoList has a number of fields that provide storage of Node Addresses. The EchoList supports "5-D" or "Domain" addressing throughout--with a twist. All places in the EchoList where you can use a node address, support the full notation: zzz:ttt/nnn.ppp@ddddddd where zzz is the zone number, ttt is the net, nnn is the node, ppp is the point (if applicable), and ddd is the Domain. Zone, net, node and point are each integer fields. Domain is a text field than cannot contain spaces. Other than that, the Domain can contain anything you need. The twist is that the EchoList allows use of the Domain field by itself to specify non-FidoNet addresses. Lets say, for example, you wanted to list your Compuserve user id as an alternate address, you could enter: MOD Mike Fuchs, 1:266/71@fidonet.org MOD Mike Fuchs, @CIS-72760.3326 But who'd want to do that... Ah well, it's a Lucky Strike extra I threw in to the NODE_ADDRESS processing routines. 7.2. NAME FIELDS In order to accommodate the wide variety of ways people want their name to appear, I've devised a really strange way of parsing names in incoming messages. In order to sort names by last name, I need to store the first name and last name separately. The line is parsed into tokens--words separated by spaces, tabs or commas. When I expect a name and address, the last token (word) is looked-at to see if it's a node address. If it is, fine. If it isn't, it defaults to the address of the sender of the message. From there, at least the last token is taken as the last name--even if it means there's no first name. I work my way backwards through the stack of tokens. I add each token to the beginning of the last name field until I hit the first token or hit a token that ends in a period (which is assumed to be a middle initial). The first name and middle initial (if present) are put in the first name field. Aren't you sorry you asked? 7.3. KEY FIELD The primary index into the EchoList database is the Tag name. Starting with version 2 the EchoList also maintains an index field called the area KEY. Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 6 Technical Reference as of: 21 Feb 1993 For the sake of standardizing definitions: "Tags" are the symbolic mnemonics used by conference distribution software. They are also referred to as Area names, Group names or Tag names. "Keys" are one-to-eight character alphanumeric codes, unique for each EchoList entry. They are generated automatically by the EchoList system based on the area Tag name you use. They are intended to be compatible with all operating system file name conventions (MS-DOS being the least common denominator). They are no more than eight characters, include only alphabetic and numeric characters, and are guaranteed to be unique within all EchoList entries. 99% of you can ignore the existence of these keys. The Tags are still used for identification as before. The Keys are an addition. Using another index as the unique key will allow multiple EchoList entries using the same Tag. The update program will allow inserting multiple entries for the same Tag by manually specifying unique Keys. Another use of the Key field is to generate unique file names for the rules files. This eliminates the chance of two moderators accidentally using the same names. It also allows accepting Rules File text in NetMail messages, with ELISTUPD creating the .RUL file here (rather than having to send file- attaches). If you want to manually specify a Key, it must follow the same rules as the automatically generated ones. Namely: It must be unique within the EchoList database, it must be from one to eight characters, and it must only contain alphabetic and numeric characters. If specified, the KEY line must immediately follow the TAG line. 8. UPDATE MESSAGES EchoList updates must be formatted and transmitted in a NetMail message as explained below. The update process is completely automated, which requires strict adherence to this format. I would suggest using a message generator such as TELL or ROBOT against a text file to generate the Conference update message. But, please DO NOT SHIP IT AS A FILE ATTACH! The information must be in the body of a message. To add or update an EchoList entry, submit a NetMail message to "ECHOLIST" at 1:1/201. The message subject is the type of processing to be done, usually "MOD UPD". The body of the message text has the data for the database entry, formatted so that every line starts with a special keyword that identifies the field name, followed by the data to be put in that field. Most of the lines are optional. If you don't want to supply data for a given field, don't include it in the message at all. The only required fields are TAG, TITLE and MODERATOR. The first line describing a conference entry is TAG. The other lines can come in any order, but TAG must come first. The CAPITALIZED part of the keyword is the minimum abbreviation you can use. The To-name, subject, keywords and passwords are NOT case sensitive. Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 7 Technical Reference as of: 21 Feb 1993 The EchoList update processor is run daily. All submissions will generate a reply message whose subject will explain that the entry was: "Accepted", "Accepted with Warnings", or "Rejected for Errors". Acceptance messages will also specify the Edition in which the update will appear. The text body will provide detailed, line-by-line edit messages, and it may also include standard epilog text appended to all reply messages as a sort of bulletin facility from me to the moderators. Syntax used below: CAPITALS are used to indicate the minimum abbreviation of reserved-word literals--you don't have to capitalize anything. Upper/lower case for passwords and keywords is irrelevant. <...> is used to indicate a value to be supplied by the submitter. There are three formats for Moderators to use; two for EchoList Entries and one for Rule File submission. 8.1. TO ADD OR UPDATE AN ENTRY To: ECHOLIST At: 1:1/201 Subject: MODerator UPDate In the body of the message: TAGname /NOSHow TITLe DESCription MODerator , PASSword , TOTalnodes VOLume / RESTrictions /SYSop /MOD-apvl /MEMber ORIGin GATEway SEENby PATH --- I've left off the KEY field to avoid confusion. If you want to override the automatic key generation, read the docs on the KEY line. If used, the KEY line must come immediately after the TAG line. 8.2. TO DELETE AN ENTRY This also deletes its Rule File if it exists. To: ECHOLIST At: 1:1/201 Subject: MODerator DELete Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 8 Technical Reference as of: 21 Feb 1993 In the body of the message: TAGname PASSword --- 8.3. TO ADD OR UPDATE A CONFERENCE RULES FILE 8.3.1. Rules File Attach In order to submit a Rules File the EchoList entry must already have been added with a MOD UPD message. Rules File messages can be used only for that- -adding Rules Files to entries that are already in the database. There are two ways to submit a rules file. The first way is to create a text file containing your rules and policies, and send it via NetMail as a file- attach. The subject of a file attach message is obviously the name of the file, and the file-attach bit must be on in the message header. The message body text must specify the Tag name and password to link the rules file to. To: ECHOLIST (as a File Attach message) At: 1:1/201 Subject: In the body of the message: TAGname PASSword --- 8.3.2. Rules File in Message Text The second way of submitting a rules file is to imbed it in the text of a NetMail message. This can allow for routing the rules file through intermediate systems. The Rules File text starts with the first line FOLLOWING the RULETEXT keyword line, and ends at the "---" tear line. During processing here, all those lines, word-wrapped at 80 characters, are written to a file named for your entry's Key. To: ECHOLIST (as a File Attach message) At: 1:1/201 Subject: MODerator RULes In the body of the message: TAGname PASSword RULEtext < . . . > --- * Note you MUST use a --- tear line in ALL of these messages after the update info and before any trailing "signature" or message text. Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 9 Technical Reference as of: 21 Feb 1993 9. MESSAGE FORMATTING DETAILS Each keyword MUST begin on a new line. Lines MUST end with a 'hard' return. Most keywords allow multiple lines to be used for fields that don't fit on one line. When multiple lines of data are provided for a single keyword, every line MUST be preceded by the keyword. The first keyword line must be the area Tag name. The order of the rest of the lines is unimportant, but it is suggested that the MODerator line be entered before any SEENby and PATH lines. If more than one conference is being listed in a single message, separate the lines for one conference from the other with at least one blank line. An update that is missing some keyword line(s) results in no change to the fields of an existing EchoList entry affected by the missing keyword(s). If you want to delete a field such that a keyword's database field is null (like dropping all Restrictions) supply the keyword on a line by itself with no arguments. Keyword lines generally replace the associated field(s) in the database in their entirety. The exceptions are MODERATOR, PATH and SEENBY. Normally, the node list for PATH and SEENBY simply replaces the entire list in the database. But, if you want to modify the list that's already there, you can prefix the keyword with a plus (+). The "+" will cause the list to be added to the existing database (duplicates are ignored). Likewise with MODerator lines, if ANY are in an update, the entire list of Moderators is replaced in the database. If (at least the first) MOD keyword is prefixed with a "+", all the MOD lines will be added to the database record. If the message subject is MODerator DELete, only the Tag name field and Password (if set) are used. The Conference will be dropped from the list, and the Rules File (if it exists) will be deleted. For Rules File updates, only the Tag name field and Password (if set) are used. The rules file name will be forced to the conference Key to make sure it doesn't duplicate someone else's file name. 10. UPDATE MESSAGE FIELD DESCRIPTIONS The following is a description of each field. The part of the keyword that is capitalized is the minimum required. The actual case of the keywords you use is irrelevant. Brackets ([]) denote optional arguments -- do not include the brackets in your message. Text character counts are recommended maximums. In reality, all text fields are variable length, and the only limitation is overall record size and my opinion of what is reasonable. A * means the line is optional. A + means the line can be repeated multiple times. Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 10 Technical Reference as of: 21 Feb 1993 MINIMUM KEYWORD *+ ABBREVIATION ARGUMENTS TAGname TAG [/NO] The "area name" used for distributing the conference. If the moderator does not want to make the area name public, you can add the parameter "/NOSHOW" (with at least one intervening blank or tab) after the area name. PASSword PASS [, ] The current password field is only required if one has been set. If set, the current password must match in order to do a Moderator Update or Delete or Rules File. To change the password at any time, simply provide the current password, a comma, and the new password. An initial password is set by leaving the current password field blank and starting with the comma. Case is ignored. There is no facility for removing a password (changing it to null). [Text 12 chars] MODerator + MOD , The name and net address of the moderator, separated by a comma. ONLY ONE MODERATOR AND ADDRESS CAN BE LISTED PER LINE. If multiple Moderators need to be listed, they will be reported in the same order submitted. Do not use middle names. If you use a middle initial, make sure it has a period. Node numbers in this field and throughout the database are stored as four integers plus a text Domain. They are input and displayed as :/.@ . The 'point' is (obviously) optional, and if the zone is not specified, the zone of the message sender is used. If no zone is found (@INTL address), the zone defaults to the zone of the EchoList processor. If the domain is omitted, but the zone matches either the sender or the EchoList processor address, that Domain text is used. If there is still no Domain, the EchoList has a list of zone-domain pairs to use as a guess. If anyone can provide me with a more complete list, please send it! TITLe TITL A SORT-ABLE title for the conference. (avoid starting with things like A, An, The...) [Text 70 chars] DESCription + DESC Describe the conference. The topics, audience, policies, and anything else that would be helpful. Don't bother trying fancy formatting. All the lines are combined and word-wrapped into a single paragraph. The following three lines, ORIGIN, DISTRIBUTION and GATEWAY are really just an organized set of free text fields you can use to describe sources and contacts that control links to the conference. Use none, any or all of them as you see fit. If you are on a formal distribution backbone of some kind, Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 11 Technical Reference as of: 21 Feb 1993 don't just say BACKBONE--there are lots of them. Specifically say "Zone 1 Backbone" or "Zone-3 Backbone" or "EchoNet Backbone", etc. ORIGin *+ ORIG If appropriate, describe the originator node of the conference. [Text 70 chars] DISTribution *+ DIST [, , ... ] If appropriate, describe the extent and/or manner in which the conference is distributed, and/or limited. Multiple keywords separated by commas and/or spaces are fine. Valid regional descriptors would be: Z1-BACKBONE, ALTERNET, ZONE- 1, REGION-13, NET-105, LOCAL-CHICAGO, etc. Restrictive values would be: NET-107-ONLY, CHICAGO-ONLY. If topology is strict, distribution node(s) can be listed as: 1:123/789. No descriptive text, please. This field is manually edited by me to some degree for consistency and reasonableness. When and if I think I've got a complete enough list, I'll implement automatic checking. [Text 70 chars] GATEway *+ GATE VIA [, VIA , ...] If the conference is transmitted via gateways to other zones or networks, use this field to specify those links. Each gateway must be a pair of expressions separated by the word "via". Each expression can be either a node number or an environment name. If multiple gateways are listed, separate them with commas. e.g.: UseNet via 999/111, Zone-3 via 1:200/999, 2:100/200 via 3:200/100. [Text 70 chars] TOTalnodes * TOT This is an estimate of the total number of nodes that are active in the conference. It is NOT a descriptive text field. It's optional. If supplied, save the editorials-- it's just a single integer number. VOLume * VOL /M or VOL /W or VOL /D This is an estimate of the number of messages entered in a given period of time for the benefit of those planning to link-in. Enter it as a NUMBER followed by a SLASH followed by the word MONTH, WEEK, or DAY. RESTrictions * REST [/SYS] [/MOD] [/MEM] This line can contain one or more restriction identifiers. It's a shorthand reference to certain Moderator-imposed rules. Enter /SYSOP if the conference is restricted to Sysops only. Enter /MOD-APVL if Moderator approval is required prior to linking in. Enter /MEMBER if participants must be validated members of some group or organization (e.g.: MENSA-ONLY). Note that these are not any-old text string you want to call a restriction. These actually set individual, pre-defined, binary flags in the Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 12 Technical Reference as of: 21 Feb 1993 EchoList database. If there are other generic flags you think should be added, let me know. SEENby *+ SEEN [ ... ] This is a list of nodes that get the conference. This is probably a total waste of space if you're documented as being distributed on one of the backbones. You can enter them in any order, and can simplify them the way real SEEN- BY lines are in messages (dropping the zone & net when they're the same as the previous node). If the domain, zone and/or net are missing from the first node, they are carried from the moderator address; if that's missing, from the sender's address. They are also carried forward from one line to the next if needed. The EchoList will automatically simplify them, eliminate duplicates, and sort them. The bottom line is, you can pull these lines straight from messages if you like. If you don't know (or care about) the nodes, but know nets, or there are too many to list at the node level, drop the node number, such: "1:107/". +SEENby *+ This is exactly the same as SEEN above, except that the list of nodes is added to the list already in the database. PATH *+ PATH [ ... ] or PATH <>[, <>, ...] There are two ways to provide this data. Internally to the EchoList database, the path connections are stored as unordered pairs of nodes. So the method of input does not affect storage in the database. The simplest method of input is to have one line for each valid node path (like the PATH lines added by certain mailers/scanners). Formatting would look like the SEENby line, but the order will indicate the actual path taken by a message, and individual lines will not be concatenated but be treated as different paths. Duplicate segments will automatically be eliminated during database processing, so you can use multiple, overlapping PATH lines from messages as the basis for this. One warning, however: long PATHs in real echo messages get "wrapped" with follow-on lines starting with PATH. This is not correct for the EchoList. Either turn such wrapped lines from an individual message into one long line, or repeat the last node number from the previous line at the beginning of the next line to show that link. Alternatively, you can provide the input in the same format that EchoList outputs it: as pairs of linked node numbers connected by the "<>" characters. Regardless of the format used, please edit-in the zone numbers and domains where appropriate. Both input formats 'inherit' domain, zone and net numbers from previous entries in the same way as SEENby lines. Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 13 Technical Reference as of: 21 Feb 1993 +PATH *+ This is exactly the same as PATH above, except that the list of node pairs is added to the list already in the database. There are a few fields that you cannot set directly, but are retained in the EchoList database. rule file name This is not a keyword provided field. If a rule file update is sent-in, the file name is stored with the database entry. date added The date the entry was originally added. last modified The date and sender of the last update message successfully processed. 11. PUBLICATION The EchoList is published on or about the first of each month. The monthly release is sent to Regional Software Dist nodes who want it (1/3xx). There is no guarantee that they will make it available for download or file- request, or pass it across zones unless you ask them. The latest version (which may include interim updates during a month) will always be available for file-request from 1:1/201 via the "magic" file name: "ECHOLIST" (no period or extension). The actual file name you get will be ELISTnnn.LZH, where nnn is the edition identifier. It will contain, at a minimum, the file ELISTnnn.TXT, the detailed EchoList report sorted by conference title. The combined rules files can be requested as "ECHORULE", which will provide a file named ELRULnnn.LZH. These instructions will be updated from time-to-time, and are available for file-request via the "magic" file name: "ECHOMOD". Which delivers the file ELMODmyy.LZH. The EchoList, it's derivative reference files, and these instructions, are all Copyright (c) Michael G. Fuchs 1988-93, and all rights are reserved. All files may be freely copied and distributed provided no charge is made for such copying and distribution, and no changes whatsoever are made to the files or their contents. Comments, questions and suggestions should be sent to me, Mike Fuchs, at 1:1/201, and are heartily encouraged. Thank you for your patience with these long-winded instructions. Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 14 Technical Reference as of: 21 Feb 1993 12. ADVANCED TECHNICAL ISSUES This is really absurdly detailed information that nobody should have to be concerned with. But, for those of you who are interested, here it is. 12.1. DATABASE IMPLEMENTATION The EchoList system was completely rewritten from the ground-up for version 2. It is implemented in C++, and utilizes an Object Oriented database class of my own. When It's "done" I will consider making the system available as a package to those who want to maintain a private EchoList. When it's available, I'll publicize it. The text fields in the database are variable length strings. Their length is not arbitrarily limited, however you can be assured I'd edit-down any text submitted that was really excessive. Seen-by node-addresses and Path node-address pairs are stored in Sets separate from the base EchoArea table, so the number of entries per area is unlimited. This, coupled with storage of node numbers in four integer fields plus a text field each, provides the maximum flexibility in reporting and analysis (like path analysis that'll get done some day). I have discovered a bewildering range of differences in message files sent from various editors. They all seem to have their own little quirks. If you know of any message editor that cannot generate a hard return under user control, please let me know with a sample message. 12.2. KEY GENERATION Beyond the internal uses for duplicate Tags and Rules File naming, interest was expressed in having a standardized source for filenames unique to each conference. I don't know whether anybody will use them, but the list of Keys are available in a couple of table files, as well as in the distributed data- file version of the EchoList. I'll also publish the algorithm, but because of the collision detection logic you can't be sure you're generating exactly the same Key as the EchoList. For what it's worth, I'm supplying them. If anybody has a use for them, let me know. How does the Key get generated? You shouldn't need to care. And I can't take credit for the algorithm, as much of it was suggested by others. But if you're curious... First, the Tag has all non-alphanumeric characters removed. If the result is eight characters or less, we're done. Next, any vowels beyond the first character are removed. (The first character is never dropped.) If it's still longer than eight characters, then we drop every fourth character. If all this hasn't gotten it <= 8 characters, truncate it to eight and we are done. Copyright (c) 1993 by Michael G. Fuchs EchoList - The EchoMail Conference List Page 15 Technical Reference as of: 21 Feb 1993 Now the Key is checked for collision with existing Keys for other Area Tags. If it collides, it has '0's appended one-by-one until doesn't collide. If it's already eight chars, the last character is replaced with a '0'. If it continues to collide, the code starts incrementing the trailing numbers until it doesn't. Anybody got a better idea, let me know. Copyright (c) 1993 by Michael G. Fuchs