Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive!psuvax1!psuvm!UTORONTO!MICHAEL
From: MICHAEL@UTORONTO.BITNET (Michael Wagner)
Newsgroups: bit.listserv.mailbook
Subject: Re: Two more items for the wish list
Message-ID: <MAILBOOK%90020212333167@UTORONTO.BITNET>
Date: 2 Feb 90 16:15:59 GMT
Sender: MAIL/MAILBOOK subscription list <MAILBOOK@RICEVM1>
Reply-To: MAIL/MAILBOOK subscription list <MAILBOOK@RICEVM1>
Lines: 53
Approved: NETNEWS@PSUVM Gateway
Comments:     Warning -- RSCS tag indicates an origin of MICHAEL@UTORVM
In-Reply-To:  Message of Thu, 25 Jan 90 16:07:15 +0200 from <VSLAWR@WEIZMANN>

>Re using the chain of Message-Ids to sequence messages:
>
>I'm at a loss to see how this could possibly be implemented in the context of
>a discussion list such as this.  Postings to a discussion list do not occur in
>a linear sequence.  There is not one single series of message-reply-reply...;
>rather, the structure is a tree form, with multiple replies possible to any
>given message.  How would you sequence two messages with the same message-id
>in the In-Reply-To: header line?  At least you would want a secondary value on
>which to sort - the date, perhaps?

Of course it's a tree.  Trees have an order.  It's just not a simple order,
and it isn't clear that you can just pass it off to the SORT command.  But it's
a very useful order.  The usual order for this sort of thing is a depth-first
tree walk, with some other key (fancy time-zone compensated date, in this case)
resolving the order of the siblings.  But, to tell you the truth, I don't
want to see them on the front screen in this order, so I don't think the
linear representation is much of an issue.  I would rather see them
clumped on the front screen as

MAILBOOK    4 items    HELP! My help contains no help
MAILBOOK   18 items    More ideas for the wish list
MAILBOOK 2001 items    More congratulations for Richard on a job well done

This allows me to find my personal mail in amongst the discussion group
mail, and allows me to skip the 2001 thank yous to Richard with a single
keystroke (I echo the thank you sentiment, mind you.  I'm just tired of
reading it over and over again).

More to the point, when I am looking at a piece of mail, I want 3 PFKeys:
PARENT, SIBLING, and CHILD.  These should use the message-id information
when it is available, and only resort to date/time/timezone/cokebottle
heuristics when more reliable means aren't available.

PARENT and CHILD are a lot like PREVIOUS and NEXT, once you have figured
out how to sort your mail correctly (which I never have).  SIBLING doesn't
seem to really exist in MAIL/BOOK.

For those who did not study computer science in English or are not
familiar with this terminology of trees, here is a diagram:

         Original Note                      If you are looking at Reply A,
             |                              the PARENT key gets you the
             |                              original note, the SIBLING
   +---------+----------+------------+      key gets you R B, R C, & R D, and
   |         |          |            |      the CHILD key gets you R R A.
Reply A    R B        R C           R D
   |
 R R A                                      By the way, I think these names
                                     for the keys would not be good end-user
                                     names for the keys.
>- Lawrence

Michael