[Pan-users] Re: sent posts??

[Duncan]

Steven D'Aprano <address@hidden> posted
address@hidden, excerpted below, on  Thu, 21 Feb
2008 12:02:15 +1100:

> On Thu, 21 Feb 2008 11:00:14 am Duncan wrote:
> 
>> Beartooth Sciurivore <address@hidden> posted
>> address@hidden, excerpted below, on  Wed, 20 Feb 2008
>> 18:44:05
>>
>> +0000:
>> > In Old Pan, I used to be able to get to copies of posts I had sent,
>> > which were often useful for a variety of purposes. If there's a file
>> > of them anywhere in New Pan, I have yet to find it.
>> >
>> >    Is there? Or is it coming back, when Charles gets to it? Or ...?
>>
>> It's not scheduled back at this time, no.
> 
> Then somebody should go and remove the falsehood on the Pan homepage:
> 
> "Pan saves your posted messages in a folder for future reference."
> 
> http://pan.rebelbase.com/features/
> 
> and replace it with "Pan defaults to throwing your data away without
> telling you."

Good point.

> Personally, I feel cheated that Pan suddenly stopped saving posted
> messages without warning. I've lost MONTHS of posts because that
> functionality was removed. Pan tells you that it saves your data when
> you send it, and then it doesn't. And this isn't a bug, it's by design.
> Unbelievable.

I agree with you (except that I don't believe I've seen pan saying it 
saves the message, the stale claim on the site not withstanding).  I 
found the loss of that feature frustrating as well.

However, neither you nor I are the pan developer, and I at least don't 
have the requisite coding skills to correct the problem.  If you do, 
Charles has always been reasonably willing to take patches (as long as 
they don't kill GNKSA compliance or some such).

>> There were various problems with the old scheme as it required pan to
>> set the message-id itself, while most posting clients let the server do
>> it. (Pan had to set it itself because it stores messages based on ID,
>> so to store posted messages they had to have an ID already.)
> 
> What nonsense. To store posted messages, Pan just needed to make sure
> that they had a unique file name. That unique file name doesn't need to
> be the message ID, it could be a timestamp, or even a string like
> "sent-message%N" where %N is replaced by an incrementing counter, or the
> first ten characters of the subject line plus a unique suffix.

Again, agreed.  But I'm not the guy doing the coding, so...

> Saving sent messages doesn't imply that Pan has to treat them as
> incoming news messages, and saving them is FAR more important than the
> ability to treat the folder as if it were a newsgroup. That's not
> important. Saving the message in the first place is critical.
> 
> 
>> There was also the issue of being unable to ever see the message as
>> everyone else saw it, because once it was posted, pan always showed you
>> the local copy, which in the case of stuff you posted, was the copy it
>> took before it hit the server.
> 
> Are you saying that when you were looking at *newsgroup* Foo, and
> downloaded your message from the server, Pan would show you the local
> copy in *folder* Bar instead?

That was a bug at one point, yes.  I don't honestly recall whether it was 
fixed in the old version before Charles stopped development on it or 
not.  The point is, his approach (reusing newsgroup code to manage sent 
messages in folders that worked rather like fake newsgroups as far as pan 
was concerned) ended up being rather bug prone.  It's possible, even 
likely, that the rewrite will eventually get another sent message saving 
implementation written, but the old approach had proven problematic, so 
there was little reason to carry it over, and a suitable replacement 
simply hasn't yet been coded into the rewrite.  Further, to my knowledge 
(and as perhaps the senior list/group regular, following pan fairly 
closely for over half a decade now, I'd be as likely to know as anyone if 
not more so), there's no short or intermediate term plans to code up such 
a replacement.

>> So Charles just cut that option entirely.  What he put in its place was
>> the save draft option.  This isn't automatic, but if you use it, you
>> get a copy as a draft, then can reopen it and send it without losing
>> the local copy.  (You only lose your draft if you delete the message
>> file pan saved.)
> 
> Tthis demonstrates nicely that the excuse for removing the
> save-sent-message option is bogus. Pan has the ability to save your
> posts as plain text files in a folder. You can do it manually. Why
> doesn't Pan just create a folder "Sent Posts" and do it automatically?

Well, what we call "new pan" is a ground-up rewrite into C++ (old pan was 
C).  As mentioned, the old approach had been demonstrated problematic, 
and a new one hasn't appeared yet.  It really wasn't a removal of the 
option, but rather, that it simply hasn't been recoded into the new 
version, yet.  And, given the low demand for it (the most requested 
features are auto-download/auto-mark-read/delete based on scores, and the 
ability to split up the subscribed group list into categories), there's 
been on mention of a redone feature of this sort being planned, either.

>> One possible workaround would be putting something in the mailto line.
>> Since that causes pan to invoke your mail client, you can then save the
>> message there, with or without actually sending it.  (You don't have to
>> mail a copy to yourself, IOW, just save it once it comes up in your
>> mail client, as you would any other mail message before you send it.)
> 
> Mail clients save sent messages, unless you explicitly tell them not to.
> You don't need an explicit "save this email" step in any mail client
> I've ever used.

Exactly... and I wish that was the way pan worked too.  Unfortunately...  
However, what I was suggesting is that once it got in the mail client, 
rather than sending it for a loop from yourself to your ISP (assuming you 
don't run your own local mail server) back to yourself, you could simply 
save it off somewhere directly, never sending it anywhere at all.  It's 
not optimal.  Optimal would be pan handling it automatically.  But I 
didn't call it optimal; I called it one possible workaround.

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