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

[Ken Murchison]

Russ Allbery wrote:
> 
> 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"


> 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?  Shouldn't the clients be dictating what is
needed/desired?


> It's all nice and good to say that implementation shouldn't drive the
> protocol, but if we require stuff that implementors can't find a fast way
> of implementing, they just won't implement the protocol, and then what
> good is having a protocol?
> 
> Dumping records down a network connection is clearly faster than parsing
> and rewriting those records before doing so.  How much faster?  I don't
> know.  It's certainly enough that as an implementor, I'd be worried about
> the speed hit and start thinking why I should bother to implement OVER at
> all when everyone already uses XOVER.

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.

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.

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.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp