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

[Steven D'Aprano]

Duncan wrote:

> 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?

Imagine if we said,

    "Should Thunderbird delete email from your Sent folder once
     it has been accepted by the receiving server?"

People would have us committed. Email is not a guaranteed delivery 
mechanism, nor is news, and proof of posting is not proof of delivery.

Auto-save as draft is an excellent idea. Frankly, it's 2011, not 1991, 
there's no excuse for not auto-saving work the user is doing, and 
automatically restoring it after a crash. (Apart from the only ecuse 
that matters in small open source projects: "Yeah, I keep meaning to 
implement it, but haven't done it yet".)

But auto-save is not the same thing as keeping a copy of messages sent. 
The two concepts are independent: you can have one, or the other, or 
both, or neither. Pan does neither. It should do both. If the message 
disappears, or gets mangled, you have no record of what was sent. There 
is no valid excuse for not keeping a folder of Sent Posts, similar to 
what your email client does.

Years ago, Pan kept a copy of messages sent. The excuse for removing it 
was that it confused the record-keeping of *incoming* messages, but 
that's a bogus excuse. Charles was doing it wrong. Pan should never have 
treated sent messages as a substitute for incoming messages in the first 
place, because messages *sent* are not the same as messages *received*.

What I send is the post as appears in the Post Article dialog, possibly 
plus a time stamp and any other headers Pan adds when sending. It is not 
a Usenet post, and Pan should not fake that it is. It should be saved in 
a Sent Posts folder. Obviously Pan needs to come up with some sort of 
unique naming scheme for the files, but it only needs to be locally 
unique, not globally, and doesn't need to match the message ID of the 
delivered post once you download it from the news server.

A timestamp and counter (in case two messages were sent at the same 
time) would be an absolutely minimum naming scheme, although there may 
be better. It's not even necessary for Pan to provide a GUI for reading 
your Sent Posts, although obviously it would be nice if it did, so long 
as Pan advertised where the files are kept so you could open them in a 
text editor. (And how to handle binary attachments?)

There is no reason at all to conflate the sent post file with news posts 
as downloaded by Pan. Trying to do so causes pain and chaos. So don't do 
it. They *are* different things. For example, I have never in my life 
written a post with a header like this:

Organization: Unlimited download news at news.astraweb.com

but on downloading my posts from the news server, I find them in my 
posts. That's fine, it is not a problem, I'm just mentioning it as proof 
that what I *send* and what I *download* are not the same message and 
Pan should not try to treat them as such.

This is what I consider to be acceptable behaviour:

(1) Auto-save is independent from manual drafts, and the locations 
should be different. Auto-save files can have arbitrary file names, 
manual save drafts must be given human readable names. Drafts 
functionality, as it currently exists, should remain.

(2) When Pan starts up, it should inspect the Auto-save location for any 
files. If it finds any, it should automatically restore them into a Post 
Article dialog box. There is no need to ask the user whether or not to 
do so, just do it.

(3) While any Post Article dialog is opened, Pan should auto-save the 
contents of each dialog (including any custom headers) every few 
minutes, with no interaction with the user (unless the disk is full, in 
which case it is acceptable to notify the user that auto-save has been 
*temporarily* disabled and continue working without it). For performance 
and battery life on laptops, if the contents haven't changed since the 
last auto-save, don't do anything.

(4) If the user closes the Post Article dialog without sending, the 
auto-save file should be silently deleted.

(5) If the user sends the post, Pan should save the post in a Sent Posts 
location, then delete the auto-save file. Pan may choose to move the 
auto-save file to Sent Posts instead.)

(6) Sent posts should not be treated as downloaded news posts. It is a 
record of what you sent, that is all. Whether or not the user then 
downloads a copy of their post from the news server has no bearing on 
whether or not they have a copy of what they sent.

(7) It would be nice, but not essential, for the user to view these 
posts in Pan itself.

(8) The naming scheme used in Sent Posts should be human readable. For 
example, Pan might choose to dump all sent posts in one directory, with 
the date/time stamp as name, and a counter for uniqueness:

Sent Posts/
+-- 2011-05-13-15:23:09-0001
+-- 2011-06-25-23:58:34-0001
+-- 2011-06-26-00:02:05-0001
+-- 2011-06-26-00:17:41-0001
+-- 2011-06-26-00:17:41-0002

An alternative might be to use sub-folders, based on the date:

Sent Posts/
+-- 2011-05/
    +-- 13-15:23:09-0001
+-- 2011-06/
    +-- 25-23:58:34-0001
    +-- 26-00:02:05-0001
    +-- 26-00:17:41-0001
    +-- 26-00:17:41-0002

Or to indicate the newsgroup sent to (but how to handle cross-posts?):

Sent Posts/
+-- alt.books.pratchett/
    +-- 2011-06-26-00:02:05-0001
    +-- 2011-06-26-00:17:41-0001
+-- comp.lang.python/
    +-- 2011-05-13-15:23:09-0001
    +-- 2011-06-25-23:58:34-0001
    +-- 2011-06-26-00:17:41-0001

or some other scheme. (My personal preference would be date-based, but 
that's just me.)


[...]
> 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.

Does anyone think that Pan needs to verify if messages post 
successfully? It doesn't do so now, and it never did. I suppose it would 
be nice to get the equivalent of a bounce "your email could not be 
delivered" message, but as I understand it, that's not how Usenet works.

[...]
> 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.

Or even just for archival purposes. Or for reference purposes, e.g. I 
often want to refer back to some post I made five years ago, when I 
posted some nice code snippet, or used a particularly good turn of 
phrase, or linked to a url... whatever. I should be able to grep my Sent 
Posts folder to find it, without having to keep local copies of 
usegroups going back five years, or without having to remember to 
manually save each and every post before sending.



> 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.

/me tries to stay calm.

Please. Do. Not. Silently. Delete. My. Data.

EVER.



--
Steven