Steve Davies posted on Sun, 21 Nov 2010 11:34:48 +0000 as excerpted: > On 21 November 2010 01:12, Steven D'Aprano > <st...@pearwood.info> wrote: >> Beartooth wrote: >> >>> But I hate to go to the trouble of crafting it all over again. I did >>> not, unfortunately, interrupt the job and save it as a draft at any >>> point.
I had wanted to reply to this thread earlier, but didn't have time... >>> Would pan-0.133-4.fc12.i686 by any happy chance have kept a copy on >>> my machine anywhere? (I have it set to use gedit.) >> >> Possibly the biggest complaint I have about current generation Pan is >> that it no longer saves a copy of posts you make, as it used to. I >> consider that a major regression, a serious problem, and terrible >> blemish on an otherwise excellent product. It was almost enough to >> drive me to another newsreader. This is correct and is one major down side of current pan. >> You might be lucky and find that gedit saves a temporary copy under >> /tmp, or whatever obscure location Gnome hypothetically uses instead. >> But probably not. Since pan's external editor functionality was used, that is indeed possible. However, based on my knowledge of how most editors work, it's unlikely, because the editor would have cleaned up any temp copies when the final was saved and the editor exited (so you don't get overwhelmed with temp copies of all the files you've ever edited), and pan would have rm-ed the copy the external editor handed back to pan when pan was done with it, for much the same reason. If there was a crash and/or abnormal termination of one or the other programs in the process, a temp copy might still be hanging around due to that, but otherwise, it's unlikely. > I'm certainly not the right person for this job, but I wonder how hard > it would be to do one of the following: > > 1) Extend the draft-saving facility to have a saved-sent that operates > on the same basis. > 2) Have a "pseudo-newsgroup" of pan.internal.sent which any outgoing > posts are automatically added into. > 2a) And then remember that cache-clearing and expiry does not apply > to that group :) > > Just throwing some ideas out there. I cannot remember how it was done > in 0.14.x as I never used the facility (my posts always come back to > me in the newsgroup I post it to :) ) The problem with the way 0.14 era pan handled it was this: Remember that pan actually stores messages by message-ID (futzing the ID a bit where a character isn't allowed on the backing filesystem, to do so). Since the message-ID is supposed to be unique, that allows it to store a single copy of the post no matter how many newsgroups it was cross-posted to, or how many servers those groups appear on. So far, so good, but what happens when pan tries to use the same method for pre-storing posts locally, before they've been (or as they are) sent to the news server? Well, a couple issues suddenly appear. 1) Now pan has to know the message-id in ordered to save it. That means that pan must assign message-ids locally, before they're sent to the news server -- it can't simply send the message and let the news server assign a message-id. With new-pan, that's now an option, since it doesn't try to save the post before sending. With old-pan, that wasn't an option, as pan had to assign the message-id so it could save the message locally in the pan.sent pseudo-newsgroup before/as it was sent. 2) Since pan only stores a single copy of a message, when that message is posted from the local pan itself, in old-pan, that's the copy that gets saved -- AND gets displayed whenever you view that post, whether in the pan.sent pseudo-group, or in the newsgroups to which it was posted. There's no easy way to actually view the message as it appears on the server to which it was posted, thus, no easy way to confirm that it posted correctly -- that it wasn't corrupted in-transit. This isn't normally a huge problem for text posts, but if pan were ever to get binary posting support, or where a tool such as my pan-attach-kd is used to attach an encoded binary, it's a much bigger issue, as the quality of the posted files may be in question. Both of these issues occasionally got complaints with old-pan, and Charles' solution in new-pan was to simply do away with the pan.sent pseudo-newsgroup and with it the pre-send saved copy feature, thus both simplifying the implementation and doing away with these complaints in one fell swoop.[1] The save-draft functionality was implemented as a replacement, allowing a user to save the message using their own filename. Now, what pan /could/ do, similar to the old functionality but with one change, both eliminating the issues described above and giving us an auto- saved sent-messages feature once again, is to generate a "special" message- id it uses ONLY for the pan.sent.messages pseudo-group. Since that message-ID won't appear anywhere else, it need-not be "globally unique" as the message-ID normally must be, to prevent the confusion of multiple messages with the same ID, only "pan unique". As such, it should be much simpler to come up with such an ID -- it could be a simple incremental, incrementing with each post, or probably better, a date-stamp with an incremental attached, thus allowing one to sort thru the sent messages raw directory (on the filesystem, not in pan) by date, if desired. Second, as its purpose is different, it'd likely be useful to use a different header, say, X-pan-sent.message.id or some such, rather than the standard Message-ID header. This would eliminate confusion and allow pan to include the standard message-id in the local copy as well, if the option to create message-ids locally (before sending to the server) is on. A conditional would need to be added to pan's code that checked the group it was in, and used X-pan-sent.message.id instead of the normal Message-ID header, if it was in that group, but that shouldn't be all that difficult in the scope of the change we're talking. ----- [1] One fell swoop: This phrase has a rather interesting history and original meaning. See for instance here: http://www.worldwidewords.org/qa/qa-fel1.htm and the phrase-google here: http://www.google.com/search?q=%22one+fell+swoop%22 -- 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
