Dan C posted on Sat, 25 Jun 2011 22:01:40 +0000 as excerpted: > On Sat, 25 Jun 2011 18:50:28 +0000, Graham P Davis wrote: > >> Had concocted a nice long post but ended the session a little while >> later and lost it. Any chance of a draft folder somewhere in the future >> so that these accidents can be avoided? > > It would appear that I have one located at ~/.pan2/article-drafts which > was put there automatically...
There's the save-draft/open-draft functionality in the compose window, but it's /not/ "auto-save", as many apps have had for years, now. As the "king of long posts" ( =:^) I seem to be, I've had a few lost posts in my time. At one point I was using the manual save-draft functionality regularly as a result, because the news provider I was using wasn't particularly reliable at posting, but all I use now is gmane and I've not had a problem with it in awhile, so I had forgotten about it. Anyway, the functionality is already there but only manual. So really, only a 5-minute or whatever auto-save is all that's lacking. But there's some implementation detail to hash out. In my case, the provider would accept posts to text groups then silently drop them if they were over, IIRC, 200 lines. Other providers might drop them for other reasons. Are we only going to protect the user from local-machine disaster and assume that once the server says it took the post, it's safe to delete the auto-save? That would be quite easy to implement. Slap an auto-save timer on the existing functionality, use a default auto-save dir and a default name per open compose window (one auto-save per window, so 1.msg, 2.msg, 3.msg... if there's three compose windows open when pan or the system crashes), delete the auto-save when the server says the post completed fine, and add a starting-pan check to see if there's anything in the auto- save dir and re-open it in a new compose window if so. But it wouldn't protect users from servers that silently drop posts they SAID, they accepted, allowing a re-post in that case. If we left the manual functionality in place too, we could punt and simply say that's the user's responsibility to deal with. But if we try to protect the user from that too, then we open a whole different can of worms, because there's no way to automatically associate the auto-saves with messages once posted, thus allowing us to auto-clean our auto-saves dir. In old-pan there was, but that was because pan assigned the message-id before posting. pan was thus able to keep a posted-messages folder as a pseudo-group, handling posted messages the same way it did normal messages, using message-id as the filename. However, that had its own negatives, the biggest being that since pan already had a copy of that message-id it wouldn't download the message as it actually appeared on the news server, so there was no way to verify that the message actually posted correctly unless one manually deleted the copy pan saved as it posted. That and related problems led Charles to omit the code assigning message-ids from the pan rewrite that became pan 0.90, thus allowing the news server to pick its own message-ids. However, without the message-id available until the message was actually downloaded, pan no longer had the message-id available to use as a filename before the download, and the auto-save of sent messages feature was therefore dropped with the manual draft save/open feature replacing it. So now pan doesn't know the message-id for a message it posts, and thus has no way to verify whether it posted successfully or not. (The new binary-posting code probably changes this a bit, but I don't know how. I'll let HMueller or KHaley, or someone else if they care to, explain that if they wish.) Not that it verified them before either, because as I said, pan simply never downloaded the message in that case since it already had a local copy of a message with that message-id. But it did have the local copy if the server didn't take it, and if the user somehow became aware of that fact, the local copy could be reposted. I suppose one way around that would be a simple post-slot based ring- scheme. Choose some arbitrary number of auto-save messages, and when pan reaches that limit, it simply deletes the oldest to make room for the next one. If the number is say 100 messages, then message 101 will replace message 1. A user would then have to track whether a message they cared about posted, and could repost it if they wished as long as they hadn't posted too many messages since -- but they'd have to figure out which of the messages in that ring it was, first. Presumably pan would display what the latest number was (1-100), so if the user knew it was the last or the third last message, they could pick accordingly, but if not... If pan used two different auto-save dirs, one for messages as composed, with presumably only a handful of messages at any one time (limited to the number of compose windows a user had open at once, perhaps only one, if a user works on only one message at a time, but presumably less than say five, so "a handful"), the other a ring-buffer of posted messages with a default ring size set in preferences.xml (thus not confusing new users with the preference, but letting those who wanted to set it to 0 to disable the feature, or a thousand to effectively keep messages for quite some time, or a million if they want to keep a nearly permanent record), then pan could handle both cases, allowing prompting on startup as a reminder if pan crashed without a message being sent and auto-delete from /that/ folder once set, plus the separately managed ring-buffer. Or pan could go back to assigning message-ids before posting and simply keep an entirely separate cache for them, presumably using a standardized extension to the message-id to keep them separate, thus allowing the usual message-id tracking code to be used in both cases. If handled correctly, this would allow a user to BOTH keep a copy of messages as- posted AND verify that they posted correctly, since the pre-posting and post-posting message-ids could be freely converted from one to the other. However, from reading Charles posts on the subject, I got the feeling he was quite relieved not to have to deal with all that message-id assignment and pre-post-tracking code he had before, and wasn't interested in reviving that sort of solution. Of course, it's not Charles making the decisions or having to deal with the consequences any more, and the new devs may decide it's worth trying. (Again, for all I know, HMueller may have already done something very similar, or come up with an entirely different solution, with his binary posting code. I simply don't know as I'm not actually a coder and thus haven't checked the code, and haven't quite followed the developments or posted comments close enough to know whether his code still lets the server choose the message-ids or provides its own, as the latter would enable less complicated nzb creation while-posting.) -- 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 https://lists.nongnu.org/mailman/listinfo/pan-users
