[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Sent posts not showing up
Re: [Pan-users] Sent posts not showing up
Sat, 12 Oct 2002 16:10:00 -0700
On Saturday 12 October 2002 13:10, Matt wrote:
> When I send a new post (doesn't seem to happen with follow-up posts),
> they don't show up in the relevant news group, when viewing with pan.
> They have gone, because I can see them using google groups. Have I
> switched something somewhere that says that I don't show my own new
> posts? Can't see why this would happen.
[Set this to both the devel and the user group. Reply set to devel.
This could be related to the "failure to mark articles posted by me as read"
problem, which I also have. Also note Friday's messages by Michael. That
bug has been reported several times, with # 90083 appearing to be the master,
that lists all the others. The last entry on it is dated 10-10, when all
current bugs were bumped to 0.13.2 target. The other entries are duplicate
notes, so it doesn't appear a lot of progress has been made on it.
Mike did trace that to the lack of an x-ref header, and asked what the
significance of that header was. Following is a bit of analysis from this
"mere user" (a bit of programming background, but not advanced enough for
Pan, just yet).
I am guessing that with the 0.12 or 0.13 betas, a new technique for handling
one's own posts was tried. The xref header, according to rfc 1036 (here:
or try this shorter link: http://makeashorterlink.com/?F27641712 ), is a
server-specific list of groups and group-message-numbers that allow it to
track what sequencial number in each group a specific message has.
IOW, the lack if the xref header on a message is a pretty strong indication
(although the header is optional, so it's not 100% proof, but most servers
operate that way, and pan obviously depends on that, see below), the copy you
are seeing did NOT come from the news server. It appears the PAN developers,
not unreasonably, decided it didn't make a lot of sense to post the message,
and then have you d/l it again, when a local copy was already available
because you posted it! (This would be particularly true for large binary
posts on a slow dialup connection, but Pan doesn't post binary attachments
yet, so...) Unfortunately, that has a number of interesting effects, some of
which we are seeing.
The effect I am most worried about is the fact that doing it this way means
the user sees the way the local copy was posted, not the way the server
received its copy. If there was an error in transmission, if said error
didn't raise a warning, it wouldn't be detected by the user, because all the
user sees is a local copy. This alone is reason enough not to use this
technique from my perspective, but I am not the Pan project owner, so I'm not
making the decision. It's a reasonably made desision, that I just happen to
disagree with, but that doesn't change the fact that it was a rationally made
The other effects as far as Pan is concerned are as we see. It appears PAN
normally depends on the xref header to track the read state of messages, with
the result being that messages w/o that header don't automatically get marked
as read, as others do. Fortunately, they can still be marked as read
manually. This only affects the user's own posts, in most cases, since those
are the only ones w/o this header. However, a server that didn't use this
header for its own tracking would cause PAN users on that server to see this
behavior for other posts that didn't get this header assigned elsewhere, due
to the fact that it is an optional header.
In your case, it appears something else is wrong, with the way PAN tracks your
own messages. Perhaps it can't save them as it does normally to the sent
messages folder, or for some other reason there is a local issue. Since it
is now displaying the local copy of sent messages, if there is something
wrong wit the storage or retrieval of said local copy, they won't display,
despite the fact that they did get to the server just fine. Apparently, PAN
is smart enough to realize that it should have your posts locally, and thus
won't retrieve them from the server as it would normal posts. Of course,
when it's NOT displaying local posts, for whatever reason, this is simply
outsmarting itself, but...
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --