[Pan-users] Re: General questions about Pan

[Duncan]

Douglas Bollinger <address@hidden> posted
address@hidden, excerpted below, on  Thu, 28 Dec 2006
20:03:04 -0500:

> I'm working on some documentation for Pan.  I have a few questions about
> some features and I'm hoping the mailing list can help.

Very cool!  Documentation has been needed for a long time!  Have you been
using the wiki or is this for it or...?  I still need to go see what I can
add, but meanwhile, it may answer some of your questions, assuming you
weren't already aware of it and using it.

http://www.darrenalbers.net/wiki/index.php?title=Pan_FAQ&oldid=1412

> With a binary post, are there any instances where a red puzzle-piece
> (incomplete) post can't be saved?  I just saved a red puzzle-piece post
> without any problems.  I assume it's corrupt, but I thought I've read
> where people were having trouble forcing the d/ling of corrupt binary
> posts.

I'm not sure on that ATM.  There have been a number of corruption bugs
fixed in the last half-dozen betas, and I'm not sure if it can be said
that all such posts can be saved now or not.

There was a point several betas ago where certain posts would save, but
the result would be a file with duplicated and out of order segments, such
that the whole file would be many times the size it should be.  The way
around that for me was to save them as text to a scratch dir, then use
uudeview to decode them.  At that time, it worked rather better for such
posts and while there would likely still be corruption (they arrived
corrupted, so...), par2 could fix them.  par2 could fix the others as
well, but pan's output was simply so large (talking several of them taking
gigs, instead of less than a gig, total), it was impractical to work with
due both to space and to the actual time required to write the gigs of
scratch out.  

I can't say for sure whether the recent bug-fixes have cured that problem
or not, but it's probably worthwhile noting the save as text, then use a
third party decoder such as uudeview to do the decoding, workaround trick,
as it's a useful trick to have up one's sleeve when you /really/ want that
file, and pan just doesn't seem to be cooperating!

> What exactly does delete article do?  I'm sure it removes the article
> from the cache, but anything else?

No, it does NOT remove it from the cache (tho old-pan, <0.90, did), so it's
a good thing you asked.  It removes the entry in pan (for that group) for
it, but it stays in the cache.  If the article was cross-posted and you
delete it from one group then go visit another it was cross-posted to and
download overviews including the ones deleted in the other group, they'll
show up as new posts, but already downloaded.  If you have already
downloaded the relevant headers in both groups, however, I believe it
deletes them for both (but again, the actual article isn't deleted from
cache).

The same cross-post behavior applies to mark-read, BTW.  If a cross-posted
post is marked read in one group AFTER the header has been downloaded in
another, it will show in both as marked read.  If however you download it
in one, mark it read, then download it in the other, it won't show as
marked read in the second.

> I understand "Show Matching Articles" and "Show Matching Articles'
> Threads," but what is the purpose of "Show Matching Articles'
> Subthreads".  The header display looks the same as "Show Matching
> Articles".

I seldom use anything but show matching articles, here, so if there's a
bug in the behavior of the others, I'd not be aware of it.  It may have
been that the conditions you were viewing in just weren't appropriate to
show the differences, but it's possible there's a bug, too.  Anyway,
here's how it's supposed to work.

Replies to a post are supposed to have a references header, mentioning
their "upline", the post being replied to, and it's parent, and the parent
of that, all the way up the line or until the references header gets too
long, in which case some clients cut out some of the older references.

Show matching articles should show /only/ the articles that match, period.

Show matching articles subthreads should show any post that includes a
matching article in its references line -- thus, the /children/ or
/downline/ of anything that matches.

Show matching articles threads should show not only the downline/children,
but also the upline/parents as well.  Technically, that's anything in the
references header of any matching article, as well as anything mentioning
the matching articles in their references header.

Show matching articles subthreads would look the same as show matching
articles, if you had the match only unread filter toggled ON, and you
hadn't read any of the subthread.  If you had read some of the posts in
the subthread but not their parents, /then/ you'd see a difference,
because matching articles only wouldn't show the read articles, while
matching articles subthreads /would/ show the read articles as children of
a matching unread article, even tho they were already read themselves.

Since most folks read in threaded order, unless a child post came in
before its parent, an unread parent would seldom have read children, so
based on that filter alone, the outcome of view matching only and view
matching subthreads would look the same.

Get it now?  Hope so, as the concept is complex enough that it's a not
easy to explain in a simple manner.  If you don't get it, however, say so,
and I'll try again, simplifying it but not necessarily covering all cases
or saying why.

> How are Supersede Article and Cancel Article supposed to work?  Am I
> right in assuming that most news servers will not honor these commands?

Some will, some won't.  In general, "open" news servers tend not to,
because there's a major authentication problem, such that impostors will
often cancel messages just to cause trouble, and one spammer trick uses
supersedes to replace legitimate messages.  Closed/private/limited-access
servers, or private groups on general purpose servers, are more likely to
allow cancels/supersedes because they have a smaller and easier to monitor
for abuse group of users.

In general, the best advice here is to always make sure you are
comfortable with what you are posting before you do so.  I make it a
policy to never post what I can't stand by and always stand by what I
post.  Altho I do occasionally have to apologize for something I posted,
it's my policy to do just that when necessary, but to own up to my
mistake, and accept that it was mine, hopefully learning from it to be
more careful the next time.  As such, I've never had to use the cancel or
supersedes functionality, tho sometimes I'll spend an hour writing a
post, only to decide it's not appropriate to post, and delete it, to either
start over again, or simply not make that post.

Thus, treat everything you post as impossible to take back, because in
effect, it is.  It's can still be symbolically useful in some instances to
say I apologize and I canceled that post, but for the most part, the
effect of the cancel is just that, symbolic.

> When you setup a news server to never expire old articles, I believe Pan
> will still delete articles when the news server does.  Is this correct? 
> Isn't this setting just for when you want to expire articles faster than
> the news server?

This is not correct (from my observations, anyway).  Consider that pan now
has multiple servers viewing the same group.  Should it expire them when
the first server does, or the last?  It uses its own settings, not what
some remote server may do.

Of course, that begs another question (yes, I'm aware of the controversy
surrounding "begs the question", but I use it in the literal meaning of
the words form, it "asks that the question be asked", if that's wrong,
well then, they should choose another phrase that doesn't have virtually
the opposite literal meaning, when I use the term, I use the literal
meaning, and do so deliberately)...

For a given group occurring on two servers, if pan is set to delete the
messages on one server in a month, and the other server in a week, which
does it do?  Based on my observations, it uses the earlier setting
(unfortunately for those wishing to keep the messages around a bit longer).

Consequently, I consider pan's per-server expiration settings a bug that
needs fixed, altho not before 1.0.  Expiration /should/ be a per-group
setting, with a global default set probably in preferences, and groups
able to set it other than the default, if necessary.  That way, there's no
ambiguity, and things expire when one would expect, not earlier or later
because there's two different settings for the same group of posts!

Of course, then there's the question of cross-posted message expiration
ambiguity.  Here, I'd suggest that pan delete the message from the group,
but check the newsgroups line and not expire it from the cache until the
last subscribed group has expired it.  That of course describes the ideal
behavior, altho it might be rather more complex to implement than
practical.

> Well, that's enough for now.  Pan's a complex program and I don't
> pretend to understand every little feature.  If anyone can help, I would
> appreciate it.

Well, hope it helped! =8^)

-- 
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