[NNTP] MODE READER

[Matthias Andree]

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

> As far as MODE READER is concerned, I personally agree with you. However,
> server implementers will tell you otherwise. If you want to argue for this
> change, please do so and let's see what happens.

I am a server implementor (leafnode) and can state that "mode reader" is
a no-op, printing 200, not switching state, in my software, but leafnode
is best described as store-and-forward proxy in its current shape, so it
won't stack up to INN (I don't care for what INN implementors might
think until I've read it), DNews or Diablo.

MODE READER to me has been the means that told INN to exec NNRPD... and
this documents there appears to be a desire to distinguish streamlined
transport facilities (within innd) from more expensive and colorful
reader facilities (within nnrpd).

NNTP is, in this respect, different from mail, for instance, which has
separate protocols for transport (SMTP, UUCP) and retrieval (POP3, IMAP,
ETRN, ODMR, perhaps something else I forgot).

I don't have strong opinions either way, on one hand the startup
overhead is considerable, on the other hand we have a lot more mode
switching around, STARTTLS the most prominent in this thread albeit in
different context, so if thinking this to the very end, the first step
would be to drop STARTTLS and other obvious mode switching, and the
second step would be to drop the hidden mode switching, such as
statefulness of GROUP command, which switches from the mode/state
"cannot retrieve by article number" into "can switch by article number".

So let's please do away with mode selection arguments.

-- 
Matthias Andree