OE 5.0 relied on the servercount information and that's why it did a pretty
bad job. Entourage actually asks for a list of all of the message ids of
messages on the server and compares this to an internal list (which is
basically how checking mail works as well). As a result, it does a pretty
good job. You can use Interarchy to see what's going on.
Dan
On 2/7/01 1:58 AM, "Michael W. Wellman" <[EMAIL PROTECTED]> wrote:
> On 02/04/2001 13:05, "Paul Berkowitz" <[EMAIL PROTECTED]> wrote:
>> I've been checking. Although occasionally command-L presents 1 or 2 brand
>> new headers from the server that have just been uploaded there, 95% of the
>> time nothing new arrives. When I click "More", I get the correct number of
>> headers (2 or 3 usually) from about 2 months ago: December 9 and 10, 2000,
>> appeared today. Since I have previously "Marked All as Read", those headers
>> should not be showing as Unread and annoying me this way, should they? If
>> this isn't a bug (albeit a different one than i first thought), what is it?
>
> Would you accept "A potential annoyance in the underlying infrastructure of
> NNTP and the various transport agents implementing NNTP"?
>
> On 02/04/2001 14:11, "Paul Berkowitz" <[EMAIL PROTECTED]> wrote:
>> Well, that could be. How do you think it would happen? Is it the server
>> rather than the news client that keeps track of "Read" and "Unread" for
>> everyone? That seems unlikely. I know that POP mail servers use something
>> called POPpers, which all work differently (one of my mail servers marks
>> "Read" correctly when I've downloaded once from that account and will obey a
>> Rule i have in place to mark as read when I download the same messages from
>> my other computer, but my regular ISP's mail server can't do this.) I don't
>> see how a news server could keep track of all its thousands and thousands of
>> users.
>>
>> Does anyone know how this works?
>
> I could tell you, but then I'd have to kill you.
>
> Oh...maybe I'll just mentally maim you...
>
>
> The news client software is responsible for tracking read/unread
> information. It generally works something like this.
>
> 1) The client connects to the server and requests information about a
> certain group.
>
> 2) The server responds, telling the client an ID number (a number that only
> has meaning in the context of this particular server and this particular
> newsgroup...and it's most definitely *NOT* the message ID which actually
> uniquely identifies each news message and would be far too sensical) for the
> first message that it has (serverFirst) and the last message that it has
> (serverLast)...and perhaps the number of messages that the server has stored
> for that group (serverCount - which one might naively expect to have some
> relationship to the value (serverLast - serverFirst)...but one would most
> often be wrong).
>
> 3) The client would have stored a ton of information from the last time it
> connected. Exactly what it stores will be implementations specific, but
> it'll generally include something like:
> prevServerFirst, prevServerLast
> firstUnread - ID number of the first unread message on the server
> lastUnread - ID number of the last unread message on the server
> readmap - usually a sparse bitmap containing no more than
> (lastUnread - firstUnread) entries...but potentially
> being larger or smaller depending upon the implementation
> numUnread - a count of unread entries in the aforementioned bitmap
>
>
> On good days, the new serverFirst and the new serverLast are monotonically
> increasing numbers. On such days, the code is easy to write and you don't
> see strange numbers for the unread count.
>
> On bad days, the new serverFirst may be smaller than the previous
> serverFirst...and the code is substantially more convoluted to write.
>
> On really bad days, the new serverLast may be smaller than the previous
> serverFirst...and the code is really substantially more convoluted to write.
>
> 4) Some implementations might actually ask how many new messages have been
> received since the last time the client and server connected. This is
> typically done with a "time stamp" based command.
>
> #####
>
> Somehow I think I didn't clear anything up.
>
>
> It's not uncommon for certain NNTP servers to arbitrarily do stupid things
> that confuse NNTP clients that haven't encountered that particular idiom of
> stupidity before.
>
> It's not uncommon for NNTP clients to incorrectly rely on serverCount.
>
> It's not uncommon for NNTP servers to lie about the number of messages
> they've received since the last connection. Especially if there is a
> disagreement between the clocks of the client and the server.
>
> It's not uncommon for NNTP servers to change their minds about just how many
> messages that they have.
>
>
> All in all, dealing with "stupid" NNTP servers is an exercise in iterative
> debugging. And if you write your NNTP client "to the spec", you'll find
> that the server screws up your lovely code.
>
> Just one of the reasons to ensure that you implement a "Mark All Messages As
> Read" that really does...regardless of what the server has to say. ;-)
>
>
> Nope...still no real useful information...but I ain't trying no more
> tonight.
>
> mikel
>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
To search the archives:
<http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>
