Re: [Pan-devel] RFC: Detecting multiparts (was: .94 weirdness with detecting attachments)

[Duncan]

On Fri 08 Aug 2003 10:49, Charles Kerr posted as excerpted below:
>
> Here's a rough draft for a better detection scheme.  I'm posting it here
> so that people can refine it and/or shoot holes in it.
>
> tools
>
>  * likely_binary_group is true if the newsgroup name contains
>    any of: "binaries", "fan", "mag", "sex", false otherwise

Possibly add .test, as some ISPs, for instance, don't put that under a 
.binaries. but under their isp name, but they often take binaries for 
testing.

>  * likely_binary_subject is true if the Subject: header contains
>    any of: "jpeg" "jpg" "gif" "tiff" "png", false otherwise

Add "mpeg" and other video extensions, "mp3" and other audio extensions, 
"zip", "sit", and friends, and "iso".  Do we want to jump in on the "exe" 
thing or is that better to leave un-decoded, forcing a manual save and 
decode?  Also, since we do yEnc, altho it isn't any longer required in the 
subject, if it's there, definitely set likely_binary_subject=true.

Discussion:

I've often wished group properties had a couple more settings.  The above 
"likely binary group" setting could be non-volatile, with the above the 
default guess, but with the setting available to the user for inspection and 
change if desired under group properties.

Were we to do this, perhaps a tri-part setting would be useful, with binary 
guessing logic changed accordingly.  Single-part, Multi-part, Text-Only.  
Anything with pictures in the name for instance would then default to single 
part, while anything with movies (svcd, video) or isos or mp3 in the name 
would default to multipart.  Single part groups would then favor parsing a 
single x/y subject segment as if it was x of y, that is a series.

~~~

While on the topic of group properties, what about including a probably 
informational read-only label there with the location of the index and etc. 
files?  A button to erase them (confirmed, of course), clearing all group 
specific info, could also be included.  The confirm dialog could then also 
mention the fact that this erases the index files but not the downloaded 
message bodies themselves, from the cache.  This would have the effect of 
resetting PAN's tracking of the group, without resetting subscribed status or 
whatever, so upon next group entry or refresh, it would be as if no overviews 
had ever been downloaded, and no messages marked read.

The above erase would be useful in two situations.  1) Changing servers or 
otherwise having a server message numbering reset.  2) Visiting a group, then 
deciding it isn't worth keeping around, but for those not wanting to erase it 
from the list of available groups entirely.

Clear as mud?  <g>

-- 
Duncan - List replies preferred.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety."
Benjamin Franklin