ietf-nntp Summary/analysis of LIST OVERVIEW.FMT responses

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:
> Russ Allbery wrote:

>> Why would the client have to assume anything at all?  That's why all
>> the fields after the first seven are labelled.  It's quite standard;
>> it's part of the original overview specification.

> I agree.  What I was referring to was what you said in your previous
> post: "they just don't use LIST OVERVIEW.FMT to figure out that they're
> there"

I'm sorry, I really don't understand what you're getting at.  I stand by
both that statement and the statement above.

>> As a maintainer of INN, I can tell you what I see in practice.  People
>> have conflicting desires and conflicting goals.  Small sites may want
>> to put large numbers of headers into overview to make them more
>> convenient;

> More convenient for who?

The clients.

> Shouldn't the clients be dictating what is needed/desired?

Yes, exactly.  :)  The clients that I have now that are using overview
with extended fields aren't going to find OVER more convenient.  It's
going to be work for them to change to HDR, and if I break XOVER in the
meantime, they're going to be annoyed.  The news.software.nntp people were
also highly suspicious of anything that required differing XOVER and OVER
implementations (to the tune of "why would I bother implementing OVER").

> Because if OVER is easier for a client to deal with (I'm not saying that
> it will be), they will choose it rather than XOVER.

Really, from the client perspective, it's functionally identical.  The
thing is, XOVER works.  If it weren't for the X, we probably wouldn't have
this discussion at all and would just standardize it as-is, because the
amount of brokenness is totally not worth making any changes.

> IMO, the clients should be dictating what needs to be
> added/removed/changed in the protocol.  If a particular extension deems
> itself useful for clients and the majority of clients implement it, then
> market pressure will force the server vendors to implement it.  Having
> servers implement what they can do well/fast/cheap and then saying
> "here's what we have to offer, deal with it" seems ass-backwards.

Oh, yeah, I agree.

> I'd like to see a world in which clients (whether they be NNTP, IMAP,
> FTP, HTTP, ...), are able to be faster and more lightweight because the
> servers take on most of the complexity.  Maybe there is just too much
> inertia behind the current usenet infrastructure for these types of
> changes to be realistic.

Well, I'm not sure that this is precisely the best place to push for that.
The really useful work in that department would, I think, be an extension
that includes OVER, HDR, and maybe XPAT too while we're at it.  There has
been some discussion of that before (usually under the name HEADERS), but
as yet no implementations.  (The basic idea being that the client can
specify whatever combination of headers and metadata that it wants and the
server will just assemble it on the fly.)

That brings up some of my speed worries too, of course.  The speed thing
is certainly overcomable; while it's rather nice to be able to just
sendfile(2) overview data across the wire, it's not essential.  I'm not
really trying to argue that it's essential so much as trying to argue that
we've got a bit of an uphill battle to get anyone to use OVER in the first
place since XOVER works, and putting stuff in that makes it hard for them
to transition or requires slower or more complicated code paths is going
to hurt our chances.

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