[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-devel] RFC: Detecting multiparts (was: .94 weirdness with detec
Re: [Pan-devel] RFC: Detecting multiparts (was: .94 weirdness with detecting attachments)
Fri, 8 Aug 2003 17:17:46 -0700
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.
> * 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
> * 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.
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."