Re: [Pan-users] Reuse/Import my old Pan v0.14.2.91's caches to Pan v0.133+?

[Duncan]

Phillip Pi posted on Fri, 25 Nov 2011 13:12:55 -0800 as excerpted:

> Hello again.
> 
> Is it possible to reuse my old Pan v0.14.2.91's caches with Pan v0.133+?
> They are in Debian, but on two different disks (old IDE/PATA and SDD).
> 
> Thank you in advance. :)

Wow, I just realized how rusty I've gotten at answering that question 
(and related), as it has been awhile!

* The cache itself consists purely of message files, and since both old 
and new versions use message-id as the filenames, yes, that works 
(barring any change in message-ID converted characters but I don't know 
any, at least for POSIX style filesystems, those trying to convert pan 
running on FAT or NTFS...).

However, the message cache itself was quite small (a few MB) by default 
in old pan, tho there was a GUI option to up it, and in new-pan, it's 
only 10 MB by default with NO GUI option to change it (option removed due 
to gnome-style (l)users-are-dummies-confused-by-options policies), altho:

* It's still possible to change cache size by directly editing the 
setting in preferences.xml.  Simply search for cache, it's not difficult 
to find.  I use settings of several gigs here, so know that works, but 
see the note below about long startup times.

As a result, when /most/ people ask the question, unless they're on dialup 
or super-expensive per-kB-billed broadband such that they're worried 
about 10 MB, or have set a rather larger cache than default (as I have), 
they're not talking about the message cache at all, so much as the whole 
directory, settings and all, and no, with certain noted exceptions (like 
the message cache), in general the data formats aren't compatible and the 
files can't be reused.

* As we've already discussed, the newsrc files should be reusable, as 
both pan versions used them.  However, IIRC renaming them was needed as 
the default names changed, I /think/.

* The scorefile is partially compatible.  The basic style remained the 
same, but old-pan allowed regex style group names (section headers in the 
raw scorefile), while new-pan is a rather stricter implementation of the 
slrn SCOREFILE format in that regard -- unlike the individual scoring 
entries, the group/section names are WILDCARD ONLY, NOT REGEX, in new-pan.

* Other than that, nearly all datafiles, including both the various group 
files storing headers, etc, and the various config files, have changed.  
That's why the default pan data dir also changed and is now ~/.pan2, 
instead of the ~/.pan used by the old style data.

* Meanwhile, there's a number of settings not available in the GUI that 
can never-the-less still be configured, by editing the text-based config 
files or in one case an environmental variable passed to pan, directly.

You already know about two, the configurable newsrc locations in 
servers.xml and the cache size in preferences.xml 

* If your NSPs allow >4 connections per server, that can also be direct-
edited in servers.xml.  Charles was a big GNKSA fan and was rightly proud 
of pan's 100% GNKSA compliance.  It's as a result of that, that the GUI 
connections spin-boxes don't allow setting >4 connections per server, 
since that's a GNKSA requirement, but Charles did arrange for the 
checking all to be when SETTING the variable, so if a user choses to 
change it by directly editing the config file, pan will go ahead and try 
to use however many connections the config file says.

(There was actually quite a discussion of this over the summer, as 
Charles is no longer the lead developer, and questions like how strongly 
pan is going to continue to support things like GNKSA, even where it 
seems rather arbitrary, as here, need to be asked, and eventually 
resolved.  FWIW, the question of GNKSA policy was asked, but not really 
resolved by that thread, except at the practical level of "we're not 
going to change it right now".  I'd highly recommend that you take a look 
at the archives if you're interested in that sort of thing, and if have a 
reasonable idea for a policy going forward, please do reopen the debate, 
probably with a new thread.)

* The server rank setting, primary/backup in the GUI, is also more 
flexible in servers.xml itself.  Pan actually honors an arbitrary number 
of levels, 1=primary, 2=backup, 3, 4, ...

* Expiration is also set per server so in servers.xml, and more flexible 
than the GUI indicates, with any any arbitrary number of days being 
possible.  So if you want something like 3 days, or 37 days, or 503 days, 
simply set it accordingly in servers.xml.

(It's worth noting here that for my pan text instance (see later), I set 
no expiration, thus keeping around the headers, and something like a 5 GB 
cache, tho I've only used < 1 GB in several years.  This effectively 
gives me unlimited retention for my text instance.  Unfortunately, due to 
the way pan is coded, that does mean a rather long startup time, > 5 
minutes, from cold-system-cache so the first time I start pan -- restarts 
remain nearly instant -- but I work around that by starting pan when I 
start kde, and pan's normally loaded and ready after I've checked mail, 
rss and atom feeds, etc.)

* While old-pan's seperate server treatment allowed one to categorize by 
setting up multiple virtual "servers", even if they actually all pointed 
to the same physical server, new-pan combines all the servers and 
subscribed groups into one big list, so that doesn't work any more.  
However, there's a different workaround:

* Pan honors the PAN_HOME environmental variable now, if it finds it in 
its environment when it starts.  So while the default data dir is 
~/.pan2, it's possible to change that by setting and exporting the 
PAN_HOME variable, pointing it at the desired location, such that it's in 
pan's environment when it starts.

* It's this mechanism that I've exploited here, setting up multiple pan 
"instances" each with its own separate data dir.  I do this using a 
wrapper script for each, pan.text exports PAN_HOME="$HOME/pan/text", 
pan.bin sets it to $HOME/pan/bin, pan.test sets it to $HOME/pan/test, 
etc.  (I actually have the wrapper script do a few other misc things too, 
but that's the big one and why I setup the wrapper scripts in the first 
place.)

One can then replace the pan menu entry with multiple entries, each 
pointing to the appropriate wrapper script.  Or, as I do, they can choose 
to launch pan some other way -- here, I use a hotkey config to launch my 
normal text instance, and only start the test and binary instances from 
the run dialog or terminal window, since I use them far less frequently.  
(Actually, I've not used anything but the text instance in some years, 
and I see that the wrapper scripts for the others are a bit stale, but 
anyway...)

Of course, you can choose the categories however you want.  Someone might 
choose one accessible from the menu, that loads animal groups for the 
kids, etc, with another that has only a command-line entry, for loading 
his "adult" groups.  Someone else might follow a whole bunch of text 
groups, and setup a separate instance for a number of different 
subjects.  Yet another might be into binaries, and setup one for movies, 
one for TV shows, one for music albums, etc.

Meanwhile, pan's quite good at following symlinks, so for configuration 
files that I want in common between my instances, I have a ~/pan/globals 
dir, which contains the scorefile, accels.text, and preferences.xml, for 
multiple instances.  Each instance then simply has a symlink in place of 
that file, pointed at the file in ../globals/.

That should be enough new-pan data to keep you going for awhile. =:^)

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