[NNTP] Snapshot 4

Andrew - Supernews andrew at supernews.net
Wed Dec 1 02:10:18 PST 2004


>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:

 >> LIST is already a complete mess and the idea of two-part command
 >> names is also a complete mess. I can't do much about the ones
 >> already there, but I see no reason to make the situation worse.

 Russ> I don't have any real opinion on this and am happy to let
 Russ> someone make an arbitrary decision unless we can come up with a
 Russ> strong argument one way or the other.  (Andrew?  You'd said
 Russ> you'd prefer LIST before as well.)

I have a strong preference for LIST in these cases:

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

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

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

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.

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.

The "making the situation worse" argument is nonsense given the number
of LIST subcommands which already exist and can't be removed. I would
argue that, in fact, changing tack _now_ to use top-level commands for
commands which would previously have been LIST subcommands is a far
worse step, introducing much more confusion than it could ever remove.

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




More information about the ietf-nntp mailing list