Re: [Pan-users] Trivial change to header-pane.cc ?

[Duncan]

walt posted on Fri, 04 Jan 2013 18:28:49 -0800 as excerpted:

> On 01/04/2013 05:20 PM, walt wrote:
>> (I'm really posting this to test the new 'sent' and 'draft' folders :)
> 
> Well, a partial success:  pan did save both of the drafts I saved on
> purpose, plus another one named 'autosave' that pan did without asking.
> 
> The problem is that when I entered the 'drafts' local folder and tried
> to read the two drafts I saved, the body panes were completely blank
> even though the drafts really were saved in the .pan2/article-drafts
> folder..

AFAIK, the new drafts functionality isn't fully activated yet, or if it 
is, I don't know how to activate it.  The compose-window's save-draft and 
open-draft functions still appear to use the old filesystem-browser based 
draft save/open functionality.

> BTW, I don't see a 'sent-articles' folder in .pan2, should there be one?

Again AFAIK from my observations both in-pan and from reading the git-
whatchanged logs, no.  The new sent (and when it gets hooked up, drafts) 
functionality works much like a normal newsgroup would, except that the 
groups are local-only "virtual" groups, never fetched.

The only reason you have a separate article-drafts subdir is because it's 
there from before and pan's still using the old functionality.  The new 
sent messages "group", however, being entirely new functionality (not 
replacing old functionality like drafts will be), is the most sensible 
place to experiment and get the bugs worked out of the concept, before 
turning it on for drafts, too.  (I'm not sure if Heinrich deliberately 
did that or if he just didn't get around to hooking up drafts yet, or if 
he tried to hook it up and missed the real action, but as it happens, 
sent /is/ new functionality so is the safest place to experiment, so 
deliberate or by accident, it's a good idea now that it's working out 
that way.  Don't break the working drafts functionality for something new 
that might NOT work, until sent is working well! =:^)

Based on what I see in my (working, but still slightly oddly working) 
sent "group" and in the pan data dir... and because writing it up here 
gives me an excuse to investigate things myself =:^) ...


The actual sent messages appear to be saved in-cache as they normally 
would be, but with a local-only message-id (and thus cachefile name, 
since it's based on message-id), so they don't interfere with downloading 
the message as delivered by the news server.  (If you have been following 
the discussion, that was one of my suggestions, based on the problems old-
pan used to have with its similar "virtual-groups" solution for sent-
messages, unless you actually manually looked up the message-id and 
deleted that file from the filesystem cache, it was impossible to see the 
message as it actually appeared on the server, since the pre-sent local 
copy's message-id kept pan from downloading it again.  That problem 
avoided, since the message-ids are different, now.)

Additionally, in the pre-send copy, the newsgroups: header has the groups 
the message was sent to replaced with the single "sent" virtual-group.  
I'm not sure if that's good or bad.  I expect it does help pan (and more 
importantly the human pan user) keep the messages straight, so the pre-
send copy messages only appear in the sent message group, so they don't 
confuse the user by appearing twice in whatever groups they were actually 
posted to, without the whole slew of additional special-case code and 
processing that could otherwise be necessary.  However, that does mean 
that if the message doesn't actually get posted, the user has to manually 
set the newsgroups list again.

(One way around that, I suppose, would be having pan set a custom-header, 
say X-pan-orig-groups: and put the newsgroups list there.  Then when 
people opened the message to possibly resend, pan could grab the list 
from that header and patch it back into the newsgroups header it came 
from.  But I don't believe the functionality for direct reposting is 
there yet either... that'd come when drafts gets hooked up, since the 
code would be very close to the same thing for reposting from drafts, and 
reposting from sent.  But of course that's an implementation detail 
Heinrich may or may not choose to implement, as is generally the case 
with FLOSS, the one writing the code writes the rules, and he's writing 
the code, so...)

Meanwhile, in normal groups that come from an actual news server, pan 
keeps track of read messages using the server's per-group message-
sequence numbering in the newsrc files.  There's no server here, and 
currently no newsrc file to match the non-existent server.  That explains 
the strange read vs. unread message behavior I'm seeing in sent.  No 
newsrc means pan doesn't have a permanent record of read messages for the 
sent "group", so it resets to all unread with a pan restart.  If you go 
into sent and read a message, pan realizes that and marks it unread.  If 
you then leave sent for another group, that's when pan would normally 
update the newsrc, but it's a virtual group without a server to associate 
a newsrc with, so no newsrc to update.  If you then reenter sent in the 
same session, pan gets mixed up and suddenly decides all existing 
messages in sent are read.  (I THINK any new sent messages since the last 
time sent was entered in that session will be marked unread, while all 
the old ones that were there when the single message was read previously, 
will be marked read, but I've not actually noticed whether it marks new 
sent messages read along with the old ones, or not.)

My (previously elsewhere) suggested solution here is to simply special-
case "sent" as always read, all the time, thus eliminating the strange 
behavior.  Drafts, OTOH, would be special-cased as always-unread, all the 
time, to remind users that they had drafts waiting... until they loaded 
and actually sent them.  Sending would presumably then delete the message 
in draft, replacing it with a message in sent, so the (normally) "unread" 
count in drafts would then actually refer to "unsent".

Finally, as with other (real) groups, both sent and drafts have group-
files in the groups subdir.  At present, drafts seems to contain only the 
boilerplate comments explaining the format, since the new drafts 
functionality doesn't seem to be actually hooked up yet.  If you've 
looked at the files for other groups before, however, once you've sent a 
few messages, if you look in the sent file, you'll likely recognize the 
familiar format, just the same as the other group files, except that the 
shorthand tables will tend to be rather shorter than normal (especially 
the groups table =:^), and a few of the article index values are 
apparently artificial/not-applicable, due to the way these virtual-groups 
are actually implemented in the pan code.

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