Re: [Pan-users] Oh, for draft folder!

[Duncan]

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