Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> writes:
Russ Allbery <rra(_at_)stanford(_dot_)edu>
I think you need to find a better example. NNTP has both article
numbers and unique identifiers.
You mean message-id? Good point. I'd forgotten that on usenet, those are
dependably unique.
Search.
That's a better example. That's not a systemic flaw, though; you could
easily add a search command to NNTP from a protocol standpoint, and there
have been various proposals for that.
The main reason why NNTP still doesn't have much search functionality is
more because of performance issues. Maintaining decent indexes, or
opening every article and trying to do searches against it with the type
of traffic volume NNTP normally handles would be difficult from a
performance standpoint. (But it might make a lot of sense for a text-only
feed.)
A better example is server-side state, which goes much more to the heart
of the difference between the NNTP and IMAP protocols.
I'm not adverse to the argument that IMAP is superior to NNTP for reading
clients in at least some situations. I've had that discussion with people
in person before. I think the IMAP protocol itself is unnecessarily
complex for that particular application, and I'm just not particularly
fond of the protocol having had to implement pieces of it, but at this
point that's kind of irrelevant given the quantity of software that speaks
it.
I think NNTP gets a lot of mindshare and neat software written for it just
because it's so simple and easy to deal with.
Speaking as (former) NNTP client author: Servers aren't always well-run,
users don't always direct their complaints in the right direction, and I
really, really, really hate complaints for a problem I can't either
solve or mitigate.
True. But this is true of any protocol. Clients *can* locally stash
message IDs and use them to adjust to renumberings; they just don't
because renumberings shouldn't happen and are quite rare.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>