[Pan-users] Re: Pan 0.119 Multiple servers. Howto?

[Duncan]

Scott <address@hidden> posted
address@hidden, excerpted below, on  Sun, 19 Nov 2006 20:55:17
+0000:

> I've got Pan configured to use three different servres.
> 
> I was expecting to find separate group lists for each server, but they
> seem to be combined into one big list.
> 
> I find that rather odd, messy and somewhat confusing.  I've not seen that
> on other newsreaders before.
> 
> My problem is that two of the servers carry most of the same newsgroups. 
> I want to switch from using one server to the other.
> 
> I see you can use different posting profiles, but how do I *read* a
> newsgroup from a different server?

Short answer, you don't (but there is a way, see below).

Longer answer, you don't, because everything from all servers is combined
into a single view, the idea being the user shouldn't care what server a
particular message comes from, only the group, and it's the client's (that
is pan's) job to present a list of posts available in a group without the
user having to care where pan gets them from, because if pan's doing its
job, all that's managed transparently behind the scenes, once the servers
are setup for it to connect to.

There are a three minor problems with that in practice, but they are
easily overcome.

The first problem is that it's a concept foreign to most news users, altho
true multi-server clients, as opposed to single-server clients that just
happen to let you configure several servers in the same app, have been
doing it this way for some years now.  See for example bnr2 and 3 (which
yes, are available for Linux, as well as MS platforms, and yes, the source
is available, altho it's in Borland Delphi/Kylex, aka a proprietary
pascal, so it's apparently not compilable with freedomware tools), which
is probably /the/ reference in terms of multi-server binary harvester.

This problem is overcome with a bit of time and familiarity, and isn't
really a technical problem but more of a problem of human nature.  Work
with it awhile and you'll figure it out and begin to wonder how you ever
did without it, IOW.  =8^)

The second problem is the very practical one of pay servers vs. free
servers, with possibly several tiers of pay servers.  While the expensive
pay server may have all the articles, getting them all from it could be
quite expensive, and is therefore rather FAR from ideal.  Ideally, there'd
be a way to tell pan to only use it if the article can't be fetched from
any of the servers costing less.  As it so happens, pan has exactly that
sort of feature, in the form of server priority or rank.  You can set that
expensive server to "fallback" priority, and pan won't use it unless the
post isn't available anywhere else.  For simplicity reasons, the pan
server preferences GUI only has two levels, primary and fallback. 
However, as with a number of other "advanced" pan features, there's
additional control available for those willing to edit the config file, in
this case servers.xml (located in the pan config dir, ~/.pan2 by default,
but see the discussion of problem three below), directly.  There, one can
set an unlimited number of priorities, thereby allowing (for example) the
user with an ISP bundled and other "free" servers, a bytes-per-month
limited pay account, and an unexpiring block account to fall back to if
absolutely necessary, to configure the three levels this would logically
result in.  Note that the single view isn't changed, but the order the
servers are ranked when fetching is.  A fallback server isn't used unless
the post isn't available at ANY server at a higher level.

The third problem is the dual one of shear numbers of subscribed groups,
for some people, and a desire to categorize them, for instance into text
groups and binary groups, or into Linux platform text groups and MS
platform text groups and ISP discussion text groups and mp3 binary groups
and pr0n jpeg binary groups and TV program movie binary groups and pr0n
movie binary groups and feature movie binary groups and...

As this point, pan doesn't have that feature directly, tho it's much
requested so there's a reasonable chance it'll be added in the 1.1 or so
timeframe (we're in very deep pre-1.0 feature-freeze now, and have been for
a couple months).  

HOWEVER, pan DOES have a feature which makes splitting up the group list
possible, somewhat indirectly.  Again, this is a bit of an advanced
feature, as it's not configured within the PAN GUI itself.

Remember above where I mentioned the default config location was ~/.pan2? 
It turns out that's configurable.  pan honors the $PAN_HOME environmental
variable.  Not only can you use this to have pan use whatever dir you want
it to use, but advanced users will have already seen the possibility to
exploit this to run multiple instances of pan.  Here, I run three, the
previously mentioned text instance (which I call just pan, tho I point it
at a non-default config dir), pan.bin for binaries, and pan.test for
trying out groups I don't know for sure I'll want to subscribe to.  Each
has its own config dir and cache separate from the others, with symlinks
used to point to common config files where I want them shared.

Here's my dir layout:

All three pan instances use subdirs of ~/pan/.  Note that it's not .pan or
.pan2, simply pan, as I prefer an unhidden dir.

~/pan/globals/ is the subdir I keep the common config files in.  For
instance, I have a single scorefile, with symlinks from the separate
configs to the scorefile located here.  Likewise, I have customized
keyboard accels (in the accels.txt file), but use the same config for all
instances by pointing to ~/pan/globals/accels.txt with symlinks.

The three instances are then ~/pan/bin/ ~/pan/test/, and ~/pan/text/.  In
addition to the symlinks pointing at the globals location for the common
config files, my binary instance has as its article cache symlinked to a
dedicated 12 gig partition, since I prefer to download to cache and then
work from there after everything is local.  That of course requires a
rather larger cache than normal.  Cache size is again an "advanced user"
config option, available by editing the config file, in this case
preferences.xml, directly.  Since my binary instance cache is a dedicated
12 gig partition, I have its cache size set appropriately.  The neat thing
is that since the configs are entirely separate, the 12 gig cache setting
for my binary instance doesn't interfere with the lower setting I have for
my text and test instances at all.  =8^)

To launch the three instances, I use three scripts, simply named "pan"
for my text instance, pan.bin, and pan.test.  In my X desktop environment
of choice (KDE), I then have three menu items, each invoking the
appropriate script, with the text and bin items assigned khotkeys
accelerators as well, so I never actually open the menu to launch them.

Here's my pan.bin script (edited slightly for posting).  The others are
similar, with changes as appropriate:

#!/bin/bash
export 
GTK2_RC_FILES="/etc/gtk-2.0/gtkrc:~/.gtkrc-2.0:~/<kde-theme-helper-config>/gtkrc-2.0"
export PAN_HOME="~/pan/bin"
cd ~/pan/scraps
exec /usr/bin/pan $*

Line 1 says execute using bash.

Line 2 exports the gtk2rc file paths, so pan uses my customized gtk theme
instead of the /ugly!!/ default.

Line 3 exports the appropriate PAN_HOME dir.  This is the line that points
it away from the default ~/.pan2.

Line 4, the cd, changes the working dir from the default $HOME.  pan at one
point had a bug that caused it to drop misc files in its working dir. This
helped keep my home dir uncluttered.  The bug was fixed but I thought it a
good idea to keep this line in case a similar bug came up again in the
future, so there it is.

Line 5, the exec, is what executes the pan executable, after I have its
customized environment setup by the previous lines.  "exec" simply tells
bash to transfer execution to the new program, so the process ID says the
same as when the script was executing.  The $* simply passes on any
command line parameters I fed the script, so I can still call it as
pan.bin --help or whatever, and get the expected behavior.

That solves the problems, leaving a nicely functioning integrated view
pan, which is far more efficient, once you get used to it.  If you
/really/ don't want your newsgroups combined into a single view like pan
does now, you can separate each server into its own pan instance using the
methods described above, but other than for categorizing newsgroups, I
think once you get used to it, you'll find pan's combined view of all
servers into the same per newsgroup headers list a significant advantage,
to the way most clients, ones with multi-server only bolted onto the side
of what is really a single server client, work.

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