Re: [Pan-users] Thread view for multiparts messages

[Duncan]

StephanB posted on Sat, 18 Feb 2012 17:14:04 +0000 as excerpted:

> can anyone tell me how to configure pan to show multipart messages in a
> threaded view?

It would of course help if you mentioned what version of pan, since the 
way pan handles that has changed over the years...  I tried to get it 
from your headers, but if I'm reading them right, you did use gmane for 
posting, but the web interface instead of the news interface, so firefox, 
not pan, so of course no pan version header in your post.

But, I'll assume it's something close to recent, say version 0.130 or 
newer...

The first problem we have is that in the news context, there's at least 
three different message variants that can be described as "multi-part", 
but the "parts" being described are vastly different, in terms of the raw 
message and pan's handling thereof.  Given that you didn't include enough 
context with your question to know for sure which of the three you meant, 
I guess I describe them all and you can pick the one that matches what 
you intended.

1) The closest match technically is to the multipart MIMEType.  MIME is 
the standard setup to allow messages to contain multiple parts and to 
properly ID and demark each part as text message, attachment, HTML, etc.  
A simple MIME-compliant message contains only one part, either the 
message text, or possibly, an attachment, say an image or sound file.  A 
message with multiple such parts will specify in the overall message 
MIMEType header a type of multipart/mixed, or some such, and each 
individual part will have its own MIME headers describing what it is and 
its relationship to the message in general, among other things.

But while this is the closest technical terminology match, such 
"multipart" messages generally appear as a single raw article as stored 
and as transmitted on-the-wire, and with certain exceptions (message/
digest, for instance), the concept of threading really doesn't make sense 
here at all, so despite it being the most accurate match for "multipart", 
it's unlikely that's what you meant.

2) Then there's message segments.  When a single message gets quite long, 
especially if it has binary attachments which tend to make it MUCH longer 
than simple text messages tend to be, most clients have a maximum size 
setting, and will automatically split the message into separate segments, 
each containing a part of the message, to be recombined at the other 
end.  Over the wire, each of these individual segments appears as its own 
separate article, but it's really just a single message that happened to 
be split into multiple individual raw articles because it exceeded 
whatever maximum single-segment size had been configured in the sending 
client.  At the receiving end, most clients can detect such messages and 
recombined them, often automatically, for display and/or saving off of 
the attachments.  In the message list, some clients will display all the 
parts "threaded" as if they're replies to the first part, but really, 
they're all part of the same message, and regardless of how they're 
displayed in the message list, as a single message, as separate messages 
all at the same level, or "pseudo-threaded" with all parts but the first 
appearing to be replies to the first part, a good client will 
automatically recombine them (at least as long as all individual segments 
are there, if some are missing a good client will display that somehow 
and not combine them automatically, but will still let the user force a 
combination of all that's there, even tho it'll obviously be corrupt) for 
display of the message body, because regardless of how many segments it 
was actually delivered in, it was originally a single message and the 
display at the recipient should show it as a single message as well.

This is I'd guess most likely what you meant.  But pan normally handles 
this /entirely/ transparently.  Since the message was composed as a 
single message before being split as it was sent, pan will display only a 
single line for it.  If parts/segments are missing, pan will note that 
with the incomplete puzzle piece icon, and the number of total and 
available segments will be shown in the subject line.  If all parts/
segments are there, it'll be the complete puzzle icon and IIRC pan will 
remove the parts notation from the subject line entirely.  (FWIW, I 
haven't done binary groups in years, so don't remember for sure whether 
it shows say 23/23 for a complete message or removes that entirely, I 
think the latter.)

Since pan lists this as only a single message, there's no way it can be 
displayed as threaded.  FWIW, this allows pan to be a bit more memory 
efficient and therefore to scale a bit better, since it can treat the 
whole message as a single object, instead of a bunch of objects, tracking 
some information only once instead of 3 or 50 or 100 or whatever times, 
depending on how many individual segments the message was split up into.  

Long ago, pan did what you describe, displaying the individual segments 
threaded.  But back then, pan would crash or simply stop responding at 
maybe a couple hundred thousand articles/segments in a group, whereas 
with that memory management improvement among others, it now handles 
several million messages in a group.  But even still, on 32-bit systems 
especially, if you get in a big group on a good server and try to 
download the tens of millions of overviews available, pan will reach the 
maximum 2G or 4G available memory and crash, well before it gets all the 
available articles listed.  It can even still happen on 64-bit systems 
with 8 gigs of RAM (I don't know that it has been tested with 16 gig 
plus), but it takes more to do it, say 10 or 50 million instead of 
perhaps 5 million.  (Numbers picked out of the air for illustration of 
scale, but it's definitely in the millions now, while it used to be well 
under a million.)

3) In groups with super-large attachments, say CD/DVD image groups, it's 
often common for a poster to pre-split the file into say 50 or 100 MB 
pieces, then post each of them as a single message, which in turn gets 
automatically split up by the client into segments/parts as in #2.  At 
the receiving end, each auto-split gets auto-recombined into a single 
message again as in #2, but there are several of them that each contain a 
file attachment that's a split-part of the original very large file.  The 
receiver will save off these individual files, then when all of them are 
available, he can recombine them using either a copy of the same program 
used to split them originally, or something like the Unix cat 
(conCATenate) command (generally with the output redirected to a file, 
thus recreating a copy of the original file) or the MSDOS copy command.

Pan will treat these as individual messages, threading them just as they 
were sent, because they /are/ individual messages.  It's only coincidence 
that the file attachments they happen to contain are all parts of the 
same much larger file, instead of stand-alone individual files.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman