Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (04/04/84)
Sorry, a misunderstanding: COM uses "message-id" och "in-reply-to" fields to keep the relationships between messages going, just like most other systems. To a local user of COM, the word "in-reply-to" is presented using the word "comment on", but this is only a matter of wording, the concept is the same and in network mail the word "in-reply-to" is of course used. Any message can be a comment on any number of other messages, and can have any number of comments on it. There is not even in COM any requirement that the graph is directed, circularities like "A in-reply-to B", "B in-reply-to C", "C in-reply-to A" can be created. PortaCOM however is a little more restricted, every message can only be a comment on one previous message (but can have several coments on it) and circularities are not permitted. This makes it possible in PortaCOM to have user commands for traversing the graph, which in PortaCOM is always a tree, in various directions. Since COM allows any number of relations in any order, commands for traversing the graph are not so easy to implement. Thus, instead, COM keeps a linear sequential list of all text items belonging to a certain "set-of-related-messages", and uses this list when someone wants to traverse or search on the set of related messages. Commands to follow the "in-reply-to" relations back and forward in COM are thus not automatically recursive, so as to avoid loops. ----------------------------------------------------------- The structure you describe sounds very similar to the way a computer conferencing system works, where your set of related messages correspond to a conference in a conference system. The advantage with this, as you point out, is that a reader of messages can read messages one conference (or topic or message-set or whatever you prefer to call it) a time, and can decide himself in which order to read the conferences, e.g. read the important conferences immediately, save the less important for another time, or even skip entirely part of a less important conference and still stay as a member of that conference. This gives the reader of messages more control of the communication process. ---------------------------------------------------------- In COM/PortaCOM we have chosen not to link the concept of "messages related by in-reply-to references" to the concept of "conferences". Any message can belong to any number of "conferences" in COM and PortaCOM, but only to one set of "reply-related-messages". These concepts are completely independent, a reply can continue a discussion in another conference. Example: One message in "experience with XYZ-ware" proposes a change in XYZ-ware". A set of messages discussing how to implement this change are written in "implementation of XYZ-ware" but can still have an "in-reply-to" relation to the original suggestion. Another difference, as it works in COM/PortaCOM, is that a conference requires an explicit command by someone to start a conference, and explicit commands to add members to the conference, either by the new member himself (for open conferences) or by the organizer of the conference (for closed conferences). A reply-set is created automatically every time someone writes a message which is a reply to a previous message. Thus, new reply-sets are created hundreds of times each day by our users, new conference only perhaps one or two a day. A conference, but not a reply-set, can also serve as a network distribution list, that is, send messages in the conference to members of the conference at remote sites. Parallel conferences can also be created between COM or other conference system on several sites, with all messages copied by network mail between the parallel conferences. --------------------------------------------------------- The basic structure of COM is a data base with the main elements in the data base being "texts", "mailboxes", "conferences" and "links". A link can be created at any time, and can link a text message to another text message (IN-REPLY-TO link) or a text message to a conference or mailbox (TO or CC link). Links can also be removed or changed, e.g. moving an entry to another conferences or linking it to one more conference, at any time, subject to some restrictions to stop misuse of this feature. --------------------------------------------------------- A user of COM normally reads one conference at a time, and within a conference, one reply-set at a time. A message is only shown once to a user, even if both the message and the user belongs to more than one conference. There are commands for skipping all or part of the messages in one conference, or in one reply-set, without reading it. Our experience is that it is very useful to have conferences and reply-sets as independent concepts, even though they serve partly the same purpose of structuring the message data base. Conferences are a more stable thing with a longer life time, reply-sets come and go every day and are created automatically, not requiring any human intervention. This is important because humans are lazy, and would not create all this structure if they had to use explicit commands to create them every time this is needed.