[Pan-users] Re: Pan on windows?

[Duncan]

Sapient Fridge posted on Fri, 08 Apr 2011 12:52:04 +0100 as excerpted:

>> There's no way of automatically downloading all bodies, unfortunately
> 
> OK, thanks for that.  I was wondering if it was a feature I'd missed or
> whether it just wasn't there.

Another point I had intended to mention with that but forgot.

Pan has nzb functionality now, and indeed, uses it for its own tasks 
file.  There are command-line options to pass pan an nzb, so it can 
download it, to keep pan "no-gui" so it doesn't popup when it's being 
called for a background task, and to automatically download headers (but 
unfortunately none to auto-download bodies, apart from a pre-filled nzb, 
anyway).

So while pan doesn't have auto-download-bodies as a general feature, if 
there happen to be nzbs available, it can auto-download the messages they 
describe.

Second additional point.

If you need full auto-download, consider installing a news server (like 
leaf-node) locally.  You can then configure it for the groups you want, 
have it do the more or less constant syncing with the server including 
bodies, and configure pan to pull only from it.  

In that sort of config, you'd naturally want pan to have a tiny cache 
again, the 10 MB default should be fine, since having both pan and the 
local news server keep copies isn't necessary.

While it would be possible to use pan's multi-server capacities to sync 
against both a local server and one or more remote servers, that's likely 
to cause various issues.  Instead, for local server groups, run pan 
against only the local server and have the local server sync against the 
others.

There is an issue with that, however, if you sync the local server to 
multiple remotes.  Unless you make special peering arrangements with the 
providers, you probably do NOT want the local server serving as a peer-
point between the remote servers, since then, any posts on one but not on 
the other will likely pass thru you to the one missing them.  If those 
posts are spam (or malware or KP or copyright challenged or...), it'll 
look to the one you supplied them to, to be coming from you, since they're 
only expecting a normal client, not a full peer.

The answer to that is to configure the local server not to upload.  But 
that has issues of its own if you want to be able to post, since pan's 
only syncing with the local server and now it's configured not to upload.

There are two answers to /that/.  First, especially for binaries which pan 
doesn't handle posting of anyway, the suggestion has always been to use 
something like newspost, which would be configured to use one of the 
remote servers directly, thus bypassing the local server for binary 
posting just as it bypasses pan.

Second, when pan starts, it examines the PAN_HOME environmental variable 
to see what data dir it should use -- ~/.pan2 is only the default if 
PAN_HOME is unset.  I use this fact here along with three stub-scripts 
that set PAN_HOME appropriately, to run three independent pan instances 
(binary, text, and test, as I'm configured, but they can be whatever you 
want), each with its own separate data dir and thus settings, cache, etc.  
The same idea can be used with the local-server case to run one pan 
instance, presumably configured for your binary groups, that only points 
at the local server, that you don't post to, and a second independent pan 
instance, presumably configured for text groups, that points at the 
various remote servers, with pan set to post to a particular one for each 
group just as it normally does.  Since pan only posts text anyway, this 
allows you to post text to the desired remote servers using the posting 
instance, without letting the local server peer or post between remotes 
for the groups for which it's configured, and use the usual separate 
binary poster for posting binaries, since pan has never handled that 
anyway.

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