[Pan-devel] Re: Generating NZB files

[Duncan]

Charles Kerr <address@hidden> posted
address@hidden, excerpted below, on  Fri, 02 Feb 2007
13:48:58 -0600:

> Konrad, what does nzbperl.pl do better than Pan? Duncan, what did you have
> in mind?

After having read the subthreads to date...

>From one of Darren's posts:

> 1) Save the attached nzb to temp and feed it back into pan.  This has
> the benefit of creating a new function that saves attachments to tmp for
> use by external applications.

> I am leaning towards #1 since it would possibly create the
> infrastructure to close 133085

After rereading 133085 and the other discussed bugs, as well as what you
brought up about a user possibly wanting to use something other than pan...

The "perfect" solution (to me anyway) seems to be obvious:

1) Work up a fix for 133085 (letting pan open files with an external
application), then configure pan as the default "external application" to
use to open *.nzb files.  That solves one angle of it, but there are
others.

2) A solution to the dual invocations of pan issue, such that calling pan
on the command line wouldn't interfere with the current pan.  This would
let pan process the new file if it continued to be associated with *.nzb,
without interrupting the current session or interfering with connection
quotas.

*IMPORTANT CAVEAT*
This complication just occurred to me, re calling current pan instances. 
I currently make heavy use of the $PAN_HOME variable to allow me to run
multiple instances of pan, one for text, one for binaries, etc.  I'd be
quite unhappy if the *.nzb task attached to my text instance, thereby
busting my text cache and causing months of cached messages to disappear!

Of course, if pan eventually implements a tree-able subscribed-groups
list, or some other way to categorize subscribed groups, one of the big
reasons I run multiple instances (and have recommended the solution to
others on the user group/list) would disappear.  Recombining them would
mean losing the convenience of the separate text vs binary cache I have
now, but that's tolerable; I just need a way to categorize my subscribed
groups lists to keep the ones I'm dealing with at the same time to some
manageable number, and I expect implementing subscribed group categories,
thereby covering that heavily requested feature, will be rather simpler
than trying to implement some way to pick the /right/ running pan instance
out of possibly several.

3) Let's not lose sight of the generating nzb files request, either. One
of the reasons I said I liked this so much is that nzb files are useful
for so many other things as well. Some of these work better if/when pan
ever gets the ability to post attachments, but I'm sure I don't have to
enumerate the potential uses of accurately generated *.nzb files,
regardless of whether pan can post them directly or not.  Of course, once
the above is implemented, pan will already have the ability to spit
generic nzb files out as temp files, so adding the ability to spit them
out to other than temp will be trivial.

So how's that for the "detailed" you wanted? =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