[NNTP] LISTGROUP wording

[Andrew - Supernews]

>>>>> "Clive" == Clive D W Feather <clive at demon.net> writes:

 Clive> Because it isn't always "painfully aware".

 Clive> It's a programming philosophy thing that I've run into in
 Clive> several places in the past. While it seems "obvious" that the
 Clive> client should be aware, it sometimes turns out to be harder
 Clive> than it looks, requiring the maintenance of global state
 Clive> across several modules.

Well, the existing protocol (the one that all the existing clients are
happily using) has no way to tell the client what group it's in, and
the clients seem to cope with that. The protocol also has no way to
return any of the other items of session state either, such as the
username or current article pointer (see below). Clients seem to have
no problem with this; the stuff they commonly get wrong is far more
basic and fundamental, like trying to issue commands from multiple
non-cooperating threads.

 Clive> The other piece of state associated with a connection - the
 Clive> current article number - can be determined by just going
 Clive> "STAT".

STAT with no parameter will fail if the previously-current article was
removed in the mean time.

Note also that use of the current article pointer by clients is
extremely rare.

 Clive> Those are orthogonal: allowing GROUP or LISTGROUP without the
 Clive> group name is *only* beneficial to obtain the group name. You
 Clive> can do that polling with GROUP already.

Allowing LISTGROUP without the group name is beneficial _because a
bunch of existing clients use it that way_, not because they want to
know the group name but because they want the LISTGROUP output. It's
common enough that we had to introduce a special cache for it to avoid
having to do an overview index scan to find the available articles (a
significant hit in large groups).

Just to make absolutely clear - my earlier comment was only about the
response to LISTGROUP, I didn't intend to suggest that LISTGROUP's
argument should be made mandatory.

So to sum up:

1) LISTGROUP with no arguments should be allowed on the basis of
substantial existing usage.

2) Requiring that the 211 response to LISTGROUP-with-no-arguments be
in the same format as for GROUP is a change to existing practice.
Clients currently do not (can not) assume anything about that
response.  (I have no problem going along with the change if it's
considered necessary, but it needs to be clearly understood that it
_is_ a change.)

3) allowing GROUP-with-no-arguments is just feature creep; adding it
at this late stage is pointless since it gains nothing. (Adding a
range parameter to LISTGROUP is something of real value to clients,
though, which is the only reason to even consider it.)

-- 
Andrew, Supernews
http://www.supernews.com