[Pan-users] Re: Feature Request

[Duncan]

Gary Jackson <address@hidden> posted
address@hidden, excerpted below, on  Tue, 12 Dec 2006
09:52:49 -0600:

> I was wondering if there are any plans to be able to post binaries to 
> usenet with Pan. Kind of like Xnews does, select the files, encode and 
> split them using yenc, then post them to one or several groups.

The feature has been requested for a /very/ long time, and at one point, a
non-functional UI for selecting the attachment was even in one of the
betas (this was years ago now, before the C++ rewrite that is 0.90+). 
However, the UI was never functional even in that beta, and I believe that
single beta release was the only one that included it.

IMO, the problem has been one of the perfect being the enemy of the good. 
"PAN" originally stood for "pimp-ass newsreader", altho that has been
substantially de-emphasised as GNOME (and with it pan, now seldom even
"PAN" any more, tho I at least tried to use PAN until 0.90's release
anyway) has gone more corporate and thus politically correct.  I believe
Charles has simply not been satisfied with single-part attachment
implementations (which would IMO certainly be better than the nothing we
have at present, functional at least for the occasional trivial
attachment), and there have always been other features to be implemented
such that a "proper" multipart attachment mechanism has never risen to the
top of the priority implementation queue.

While I can't complain about what pan has done and where it seems headed,
as the fact that I am using it and have devoted all this time to
volunteering on its lists over the years speaks for itself in what I
think of pan vs. the other choices out there, certainly now with the new
multi-server implementation, there remain two major features yet to be
implemented.  One is attachment posting, in at least trivial single-part
form, which I really don't understand why it's not there yet except as I
said that Charles simply hasn't been satisfied with any solution he has
come up with.  The other is a "properly full" scoring implementation,
functional on all headers and the entire post, not the
limited-to-overview-data version we have now.  The fact is, it's simply
too easy for those that wish to to make themselves a nuisance by
nymshifting and the like, thus avoiding the limited scoring solution
available now.  I'd have preferred even a three-way kill/normal/watch or
even a binary kill/normal filtering solution that could work on the entire
post, to the scoring that works only on a very limited header subset, that
we have now.

Of course, I'm not the developer, nor do I have the necessary skills, so
it's not like I have much room to criticise.  Again, as I said, the fact
that I'm using pan and spending the time I do answering questions on its
mailing lists speaks for itself that I consider it the best option out
there, for *ix anyway, ATM.  Still, I've a right to voice my own opinions,
recognizing them as such.

Anyway... back to the problem at hand...  There are three possible
workarounds, ATM.

1) Keep something that /does/ do attachments, like knode, around, as well
as pan.  I did this for years, to use for that trivial attachment case,
but removed it recently in favor of workaround #3 (which I'm naturally
preferential to) below.

2) For the real serious binary posters, those who would be using power-post
or the like on MSWormOS, there's the command line and batch-posting
oriented newspost.  There were formerly two GUI frontends for it,
gnewspost (GNOME 1 based I believe) and knewspost (KDE 2 based), but
neither of them has been updated in a very long time and hasn't worked
with current versions of either desktop environment for quite awhile as
well.  Thus, ATM, newspost is for all intents and purposes a command line
option only.

3) As the question has come up over the years, I used to mention that it
was theoretically possible to develop a pan "plugin" of sorts, configuring
its external editor functionality to call a script, which could then
attach a file as appropriate, and hand the message including the attached
file back to pan for posting.  After posting the same thing a few times, I
began to add that I might even get around to creating such a script at
some point.  Well, a few times later, I did just that, altho at first it
was a very rough proof of concept more than anything else.  I had hoped
that someone with either better scripting experience or real C/C++
programming ability would take my proof of concept and run with it, making
something rather better, but it didn't happen, so sometime later I
improved it, adding kdialog support instead of depending on keywords
inserted in the message body in pan before invoking the script.

Making it graphical had the desired effect and a couple folks have
submitted patches to improve it further.  Unfortunately, I hadn't had time
to get back to it recently, so those patches have been just sitting. 
Maybe this week... as I've said to myself week after week for several
months now...

Anyway, the current release, such as it is, of both the original script
and the kdialog graphical version, are available on my webspace. 
pan-attach, the original script, requires uuenview, from the uudeview
package, to do the actual encoding.  It's deprecated as I'm not aware of
anyone that actually uses it, but if you have patches, I'll consider
them. pan-attach-kd, the kdialog version, requires that kdialog be
installed as well.  kdialog is part of the kdebase monolithic package,
which must be installed along with qt and kdelibs, to use the -kd version.
I'd welcome someone creating a zenity (the new name for the former
gdialog, AFAIK) or xdialog version as well, as I recognize the KDE
dependencies will be rather heavy for those without it otherwise
installed, but I use KDE and don't have zenity installed or know anything
about scripting xdialog, so if someone's interested, they'll have to do
the work themselves.  The license is currently GPLv2 but I'm considering
switching to CC's attribution/share-alike license and will almost
certainly go GPLv3 on its release otherwise.

Both scripts are available at:
http://members.cox.net/pu61ic.1inux.dunc4n/

They are deliberately posted with the executable bit turned off, so you
can examine them before deciding to run them, if desired.  Turn the
executable bit on and run them from a command prompt with the standard
--help parameter to get instructions.  They've worked for a number of
folks, so should work for you.

One caveat with both pan-attach scripts is that for technical reasons,
MIME/base-64 encoding isn't possible using the external editor
functionality -- there's simply not enough control of headers and the
like, as only the message body is sent to the editor, not the headers. 
Further, new-pan won't do yEnc encoding either -- the edit widget pan uses
chokes on it.  Thus, the only true encoding available with the script and
pan >= 0.90 is the old UUE based encoding. =8^(  There's another "encoding"
option too, text/identity, but it just includes the file as is, unencoded,
thus being suitable for including text-based files but not binaries.

4) This one isn't available yet and I can't say if or when it will be, but
based on my experience with the above, I'm considering implementing a
kdialog front-end to newspost.  (Or maybe a python based solution instead
of bash based.)  Given that it would be a front-end app in its own right,
not just a helper script for pan, and given that both gnewspost and
knewspost seem to be dead, there's a moderate chance this might actually
get picked up by some of the distributions, if I did it right.  Thus, it'd
be important to get licensing and the like correct.  Thus, the experience
with pan-attach* will be useful in getting this one right, if I ever do
it, that is.

Of course, if you've the skills to do it yourself or persuade someone
else to do so, I'd be perfectly happy if someone else implemented a
newspost frontend, so I didn't need to worry about it. =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