On Oct 04 2004, Martin Trautmann wrote:
Here's an example from pentax-discuss(_at_)pdml(_dot_)net:
September 2004:
Msgs: 7642
Mbox: 23 MB
Thrds: 668
noref: 1093
That is: 1093 of 7642 messages lack either References or In-Reply-To and
are grouped together by Subject only.
Having a closer look at the threads, I see that 80 of 668 are not new
threads but could not be grouped to the matching thread since neither
matching subject nor References were given.
That's 15 % which lack proper references!
Very nice example. You've convinced me. Either we have to wait
for the world to upgrade their MUAs, or we have to find some other
computationally cheap way of discovering thread structures.
Concernint the numbers above, I'd recommend this highly for digest modes.
It would not be the thread only, but both a thread ID and a subthread or
message id within this thread.
In fact it would result in a very long thread id - so the easiest would be
just to compose a subject from maybe 'Re: ', Original Subject and
[<message-ID>] which would be filtered by comparing the message-ID and
references - and putting it in there if omitted.
The example I gave was just to keep the idea easy to see. If implemented
by a list server, I would expect some internal hash number for the parent
node within the thread tree. The id number inserted in a subject would
not need to be descriptive for humans just an opaque label.
However, if you also expect the recipient's
MUA to use those ids as hints for the display of the thread, then
the embedded id would need a simple structure, such as you propose below.
How about the answer to Antw: Re: this is an example subject (thread-id
7.1)? Should be [tid: 7.1.1] - and not only [tid: 7.3]!?
Worst might be (or is) a virus that takes the sender's subscribed name,
sends to the list and blocks the list itself by e.b. mass postings,
virusses, huge attachments or even list server commands which are
attempted to process.
That's already a problem. Nothing to do with threads, but a serious
problem nevertheless.
For the case of a courtesy copy, if every list member wanted one, the
effect would be insignificant, since only the parent poster should
receive a courtesy copy.
That's not necessarily that helpful - maybe the answer to the answer was
the more interesting part.
I think the question has to be: is there a mechanical benefit from
letting the list server perform some actions which are already performed
by list members individually? As a result, the list members' MUA software's
shortcomings could be overridden by the list server acting as a proxy.
If you like, another way of viewing this is:
The combination of (MUA + list server) would act as a MUA with both
local (on the user's PC) and remote (on the list server) components.
The remote component can be upgraded (for bug fixes, standards
compliance etc.) without requiring each list member to upgrade their
preferred MUA. A message is composed on the local MUA, transmitted to
the list server, which rewrites it according to user preferences and
the list standards, and finally transmits it to the other list members.
An intelligent list server could perform many more, new things as well
(e.g. your examples), but all of this is getting very off topic
for the 822 list.
--
Laird Breyer.