Message-Id: <v03110714b096be70351e@[130.237.158.12]>
In-Reply-To: <3470A0F3.9AD37875@netscape.com>
References: <Pine.SOL.3.95.971107163558.5497J-100000@eleanor.innosoft.com>
   		<6hTs-VGHw-B@khms.westfalen.de>		
 <971108073725.ZM1859@candle.brasslantern.com>	
 <v03110794b094f554c4bb@[130.237.150.138]>
 <v03110700b09603844048@[130.237.158.12]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Nov 1997 04:48:56 +0100
To: Jamie Zawinski <jwz@netscape.com>, drums@cs.utk.edu
From: Jacob Palme <jpalme@dsv.su.se>
Subject: Re: Deprecating In-Reply-To???

At 11.54 -0800 97-11-17, Jamie Zawinski wrote:
> Oh, but
> wait -- nobody actually implemented anything that really took advantage
> of the old 822 definition of References.  What they implemented was the
> 1036 definition, because they actually understood how to do that in a
> useable way.

We did. In the KOM data base, messaging is seen as a data base of objects
and links. Users, newsgroups, mailing lists, messages are objects.
"In-Reply-To", "References" and "Supersedes" create links between
message objects and other message objects, just like "From" and "To"
create links between message objects and user or mailing list objects.
Any object can have any number of links of any kind. There are basic
data base commands which will give you all the links from or to
an object, or of a particular kind from or to an object. If the same
message arrives more than once with the same Message-ID, then the
set of links will become a join of the old and new set of links. All
links are stored bi-directionally, i.e. searchable from either end
of the link. All links also have a creator (the author of the
message introducing the link) and a creation date (the date of
this message).

The advantage with our implementation is that a user can in simple
ways find
- which messages is this message a reply to
- which are the replies to this message
- show, scan, search through or print all messages in a thread

The disadvantage is that the original messages are not left. Because
of that, in som variants of KOM we stored messages twice, once
in the data base format of objects and links, and once just the
incoming RFC 822 messages unchanged. This allowed us to send
messages out without munging the RFC 822 header, which would
have occurred if we recreated the RFC 822 header from the link.

Our users have always found the strong support for threads and
links in KOM as an important advantage and complained about the
lacks of such support in most e-mail software toay.

------------------------------------------------------------------------
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme