It now seems generally agreed by all users that the problem arises in
Entourage only with newsgroups on the Microsoft Public News Server. (I
subscribe to some groups on a private MS server, and there's no problem
there even.) Why might that be? It is quite a nuisance, although the
option-command-T, applied about 100 times a day, works fine every time. Is
that the best that can be hoped for?
--
Paul Berkowitz
On 2/7/01 5:18 PM, "Dan Crevier" <[EMAIL PROTECTED]> wrote:
> 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/>
