[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-users] Re: attachments
[Pan-users] Re: attachments
Tue, 26 Jul 2005 09:22:34 -0700
Pan/0.14.2.91 (As She Crawled Across the Table)
wayne posted <address@hidden>, excerpted below, on Mon, 25
Jul 2005 11:37:49 -0700:
> I've been using pan for a number of years and love it. One thing
> that has always bothered me about it though is that I cannot view
> the attachment name(s). Is there any way to do that? Sometimes
> I'd like to know what it is before saving it to disk.
There is no such functionality at this point, other than directly viewing
the source of the post (saving that, or opening it from the cache), and
gleaning the attachment name and other particulars from the raw post.
However, I too would find the ability to see that information, either
displayed by default, or at least available, useful.
> Another complaint is that posts with attachments don't always appear
> when I have filtering set to only display messages with attachments.
> This is especially true if the message title starts with "Re:". I
> click off "Match Only Complete Attachments" and then they show up.
> I guess pan doesn't see them as complete.
The problem is, detecting just which posts indeed have attachments is very
difficult, particularly if attempted with only the overview data, before
the post itself has been downloaded. PAN makes its best guess, based on
the title, generally (Does the title have something that looks like a
filename in it? What about part number hints?), but this isn't always
correct, particularly where it comes to replies to a previous post, where
the subject line reflects the original post's content, giving no hint of
what the followup contains.
As PAN is currently coded, it makes the determination of the type of post
based, as I said, on the subject of the post, because that's available
before actual post download. At some point in the future, that could be
made more accurate after download by including a routine that re-checks
the downloaded post content to determine whether it actually is/has an
attachment or not, correcting the little icon as necessary. However,
since the main pain is usually in the downloading itself, the usefulness
of such a feature would be somewhat limited, except in regard to
post-download scoring and the like, if that's ever implemented (currently,
scoring works only on overview content as well, thus preventing one from
scoring on, say, nntp-posting-host, or other useful content or headers not
normally in the overviews).
If the NNTP spec had been designed with binary attachments in mind, things
would be very different. However, the protocol was originally designed
for text messages only, and methods for creating binary attachments are
only a crude workaround for what is still officially only a text based
protocol. Thus, basic information like whether the post is actually text
only, or has binary attachments, and what they may be if so, simply isn't
part of the specifications for the protocol, leaving client software to
make its best guess based on what is after all only community convention,
not part of any formal standard definition, that of putting attachment
info in the subject line. By definition, therefore, any attempt to make
sense of that non-standardized information in the subject and guess at
whether that means there's an attachment and whether it's complete or not,
is prone to mistakes.
OTOH, if NNTP /had/ been designed for binary file transfer, I'm sure it
would have been targeted far more heavily by the copyright violation and
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 in