At 9:48 AM -0400 4/11/01, James M Galvin is rumored to have typed:
> However, digests are popular for "unusual" reasons, too.
Yup...when used as the _only_ version of a list available, they make a
great throttle on the "Me, too" and other knee-jerk responses. But that's
from a listmaster's perspective, not the end user's, and not something I'd
recommend to others.
> I just did a
> quick check of my lists and discovered that as many as 3% of subscribers
> are on both the discussion list and the digest list when a list supports
> both. I'm not even going to try and explain that one.
I explained my personal reasons in an earlier message referencing why I am
subscribed to both versions of some lists, including this one...the
interactive is for immediacy when I am involved in a current thread (since
some people don't send direct copies of list messages, it's almost impossible
to answer questions without considerable lag time if one is subscribed to a
digest only), where the digest is for perusing when I'm not as well as
archival/reference purposes. I don't suggest this is the way it _should_ be
done, only that it is the way that works best for _me,_ which is the whole
point of having the choices in the first place. (Maybe I've been doing this
too long, but I don't personally either want or need an email client to do
the threading for me...I can handle multiple threads just fine in my head
reading a straight digest. Again, though, someone else _might,_ so you're
correct that the ability should be there.)
At 10:25 AM -0400 4/11/01, James M Galvin is rumored to have typed:
> Point 2:
<snip>
> So, in the interests of not having a multipart in a multipart and
> thus keeping the table of contents with the digest, the Subject:
> header seems like a good candidate as the minimum header.
You could also add a From: header field here pointing to the list
manager/maintainer/responsible human. (This is completely unnecessary with
the List-Owner: header field, of course, but no one seems to use any of the
List-* fields I provide, and I've discovered to my horror that some clients
don't even bother displaying them without jumping through hoops.) For those
clients which exploded the list into seperate messages, this could be a
method for communications from subscriber to responsible human. (Of course,
this begs the question...do we really _want_ that? ;)
> Point 3:
<snip>
> However, I don't see any reason why a multipart/digest could not
> have exactly one part in it which was the list of subject header
> values with each one linked to the actual message, as suggested
> elsewhere on this mailing list. In fact, I like this idea.
Which sounds like a great idea, but I'm pretty sure it can't possibly be
implimented with any hope of it functioning across email clients. Assuming
the client doesn't "explode" the issue into seperate segments per message, I
suppose you might be able to jump down to the seperate messages within the
same email using links (although none that I'm aware of outside of text/html,
but as I've displayed before, what I _don't_ know fills libraries). Some
clients explode into seperate mailbox files, some into seperate disk files
per message, some into ways I haven't seen yet, and some don't explode at
all, I don't understand how you could possibly find something that worked
consistantly across email clients without running a multi-year RFC cycle
which would be ignored by most large client publishers anyway. (Man, I'm
getting really cynical as I get older...)
Web-based archives, which I despise and refuse to use because of the
harvesting of poster's email addresses by the spammer scum, shouldn't be
worried with the digested version, anyway, since they have the interactive
copies, and all threading and such can be done there easily. So the only
issue I see is linking within the digest message itself, and again I don't
understand how that would be possible cross-client. Can you suggest methods?
Charlie
--
Real courtesy starts with not dictating requirements for personal email,
or at least not expecting all your mail to meet /dev/null when you do
