pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: attachments


From: wayne
Subject: [Pan-users] Re: attachments
Date: Sun, 07 Aug 2005 22:46:51 -0700
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050716)

Duncan <address@hidden> responded:
>> 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.

Yes, I have been working around this limitation for awhile.  I think
it would make a great enhancement.

>> 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 censorship crowds...

This explains a lot about pan's behavior.  Thanks.  I looks like a
problem for all newsreaders.  The method I use to determine if there
is a binary attachment is to examine "lines".  If it's over 1,000,
then more than likely there is an attachment.  I have, on occasion,
seen messages with 10 lines that have an attachment however.
BTW, what does "lines" actually mean?

Thanks,

-- Wayne.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]