Re: ietf-nntp Issue: empty groups

[USENET news manager <[e-mail]>]

Jack De Winter wrote:
>>[about GROUP response for empty groups]
>Basically, I would like to see a clear indication that a group
>is empty.  I thought that the article count could do this, but
>people were saying that there were weird cases that would not
>allow us to set an empty group to 0 articles.

I don't recall anyone saying that, only that some servers might not bother
giving any indication that a group was empty, simply returning the low article
number from the last time it was updated, and the highest assigned number, 
and a non-zero estimated count appropriate to those bounds. Basically, no
different from the case where all but one article in that range has been
cancelled, except that the final remaining article is missing too (and
indeed, it may have been there when the GROUP response was sent, and
cancelled before the client went looking for articles). It's also what the
same client would see if it looked directly at the server's "active" file
(as many UNIX clients, at least, can still do).

It's preferable for the server to identify empty groups as such, for
efficiency reasons (and so the client can avoid wasting the user's time by
offering the group for reading), but the client has to handle that case
anyway since it could arise due to cancellation between the GROUP response
and article retrieval.

>Thus, fall back to using the first and last article numbers.  This
>means that we need some clear way of specifying using either/both
>methods.  Setting first = last + 1 (or at a minimum first is some
>value greater than last) and the number of articles to 0 is the
>most unambiguous way I can think of.  Setting first = last is
>really confusing.

I'm not convinced that it's confusing or a problem. In all cases where the
server bothers indicating that the group is empty, the count should be zero.
If the count is non-zero, the response should be handled as for any other
normal response. Setting first=last=0 omits some information which could
be of use to the client, but the equivalent information will become
available the next time the client looks when the group isn't empty (and
waiting until then could actually avoid some special-case processing).

The discussion really centred around what meaning, if any, could safely be
attributed to the low and high article numbers when the count is zero. My
interpretation of the discussion so far is that in all the cases which are 
believed to arise in reality, if the high article number is non-zero (when
the count is zero) then it will be the highest article number assigned so
far in the group, and can be used (for example) to mark all articles up to
and including that one as read. If it's zero, it should simply be ignored 
and the articles can be marked as read by reference to the low article 
number seen in the next response for that group which has a non-zero count.
(And doing that in all cases, never doing it for count=0, actually 
simplifies things for the client by avoiding some special-case handling.)

The low article number provides no useful information for the client when
the count is zero.

                                John Line
-- 
Cambridge University Computing Service - USENET news manager. Usually John Line
[e-mail]    (alias {newsmaster,news,usenet}@news.cam.ac.uk)