pan-users
[Top][All Lists]
Advanced

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

Re: [Pan-users] cached articles marked as read?


From: Duncan
Subject: Re: [Pan-users] cached articles marked as read?
Date: Tue, 22 May 2012 07:27:51 +0000 (UTC)
User-agent: Pan/0.138 (Der Gerät; GIT 169a3a7 /usr/src/portage/src/egit-src/pan2)

Duncan posted on Tue, 22 May 2012 06:37:19 +0000 as excerpted:

> Vito 'ZeD' De Tullio posted on Mon, 21 May 2012 20:02:36 +0000 as
> excerpted:
> 
>> I have a bad connection, and I want to automagically fetch all new
>> headers + body of the newsgroup I subscribed.
>> 
>> I found at "Edit" -> "Edit preferences" -> "Actions" a way to cache new
>> articles, settings the value "Only new (score == 0)" at the third drop
>> down menu (labeled "Cache articles scoring at").
>> 
>> 
>> Unfortunately, I found that the messages are also marked as read! If I
>> do <shift>+a ("get new headers in subscribed news") I can see the
>> layout pane with some new messages, but if I select a newsgroup I found
>> no unread messages!
>> 
>> 
>> Is this intentional? Is a bug? Is there a "correct" way to cache all
>> new messages in all subscribed groups?
> 
> This is quite new code, this year, and hasn't had a lot of testing yet.

[History deleted...]

OK, looking at the actions tab in preferences, I now see that the text 
description isn't quite as clear as I envisioned.  I'm not sure if the 
functionality works the way I had envisioned, or more like it actually 
states.  As I said in the previous post, while I (re)described from and 
old discussion what HM implemented, I've not actually tested it as I 
haven't done binaries in years and text doesn't really need at least the 
auto-cache/download as much.

The way it's /supposed/ to work, you tell me if it does...

The four actions work on scores (that much should be clear), with each 
acting independently of the others, except of course that if a message is 
deleted, that's obviously it, the other actions won't have a chance to 
take place.

The two "negative" actions, delete and mark-read, are supposed to work on 
messages scored AT OR BELOW the specified score category, while the two 
positive actions, cache and download, should work with messages scored AT 
OR ABOVE the specified score categories.  The AT OR BELOW, AT OR ABOVE 
bit isn't clear in the current interface, and as I've not tested, I 
actually don't know if it works that way or not, but that's how it's 
SUPPOSED to work.

So if you set CACHE articles scoring at... zero/new, then it should CACHE 
articles scored above zero as well.

Does it?

Meanwhile...

You didn't specifically mention... what are the other three actions set 
to?  Are they all disabled, or do you have them set to a score category?  
Obviously, the mark-read action is the one we're most interested in here, 
but deleted would also have potential to interfere.  Just making sure we 
don't have unintended interference.

The general idea, meanwhile, was to allow something like this:

Automatically:

Delete messages scoring at or below: [-9999] (ignored)

Mark-read messages scoring at or below: [-1] (negative)

Cache messages scoring at or above: [0/new] (all not negatively scored)

Download attachments for messages scored at or above: [+9999] (watched)


But, by having the configuration available, people who wanted to could 
disable all actions, or for instance set delete on anything negative, 
auto-mark-read 0, leave +1 to +9998 alone, and auto-cache (for text) or 
auto-save-attachments (for binaries) watched.

Of course, that would also allow someone to set both delete up thru +9998 
and auto-save down thru zero, if they wanted, which obviously couldn't 
work, as the messages in the overlap would be deleted before they could 
be saved.  But we trusted people to be smart enough not to do stuff like 
that, except possibly for testing, to see that it would actually delete 
before save and not crash or something.

Also, not directly related, but *IMPORTANT:*

Pan's cache is only 10 MB by default.  For binary message caching, you 
*WILL* need that larger.  While that's a decent number of text messages, 
if you're trying to cache binaries at all, that's TINY!

I routinely run a cache of several gigs for both my text and binary 
instances (which I keep separate).  On the text instance, I have messages 
set to never expire, with a multi-gig cache (tho only a bit less than a 
gig actually used) to ensure that my text message archive of several 
years stays around.

Back when I ran binaries, I had an entire partition of some 12 gigs 
dedicated to binary cache.  My routine was to grab overviews/headers, 
download a message here or there to get a sample, delete what I knew I 
didn't want, and set the rest to download to cache.  Then I'd go to work 
or to sleep or whatever and come back later, when everything was cached 
locally, to sort thru things and actually save them off somewhere, or 
delete them.  I remember when I first started with pan, being confused 
because I had set it to download a bunch of stuff, but when I came back, 
very little of it was still there, because the cache was only 10 MB and 
it had deleted stuff as fast as it came in, after that!

By contrast, the original intent (from long before pan even had scoring) 
was obviously to have people directly download and save off attachments.  
For that, a 10 MB cache is generally sufficient, enough to decode and 
save off the binary as it reaches completely cached, then delete the 
individual message parts composing it to make room for the next one.

So, if you're caching binaries, be *SURE* you have pan's cache (first 
page of prefs, behavior) set large enough for the binaries you want to 
cache!

But if none of that's the problem I think I might know what is.  Next 
post...

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




reply via email to

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