Douglas Bollinger <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
