[NNTP] Snapshot 4

Russ Allbery rra at stanford.edu
Wed Dec 1 02:21:34 PST 2004


"Andrew - Supernews" <andrew at supernews.net> writes:

> I have a strong preference for LIST in these cases:

> 1) The command makes no changes to server-side state

CAPABILITIES certainly fits here.

> 2) The command returns a list of items in a one-per-line format, where
> the results are either constant or mostly constant (for a specific
> server configuration or state), or are obtained from a scan of the
> active file against a wildmat qualifier

Likewise here.

> 3) The command isn't used very frequently (LIST ACTIVE is the only
> existing LIST subcommand that gets heavy usage)

This is where I don't think that it does.  If clients do what we're going
to tell them to do, CAPABILITIES will be used at least once a session,
perhaps more.  That may still not qualify as very frequently, but I think
it's still as frequent as LIST ACTIVE or perhaps more.

Certainly my intention is to hard-code the output of the command except
for SASL mechanisms and the needed switches to add or remove commands that
aren't available for a particular session and make the command reasonably
fast.  Note that currently in INN, we weren't able to share code for LIST
EXTENSIONS with the other LIST commands (most of which do all share code).

> There's a lot of common code in handling LIST subcommands in existing
> implementations (both client and server), despite the rather ad-hoc
> nature of the response formats of the existing subcommands, and it makes
> sense to me to take advantage of that rather than put lots of new
> entries in the top-level command table.

Agreed in general.  CAPABILITIES does feel somewhat special to me,
although I could be convinced otherwise.

> For the same reasons, plus the whole "last-minute major changes" thing,
> I am strongly opposed to changing any of the existing LIST subcommands
> in the spec (LIST HEADERS etc) to top-level commands.

I strongly agree with you here.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list