Gary Jackson <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users