Russ Allbery writes:
Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> writes:
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.
I agree.
I don't know whether the search command was in the very first IMAP
version. I suspect not. Doesn't matter really. My point is that once
you add the features that are sensible for reading mail, you'll have
something roughly as complex as IMAP, and I conjecture that it would
have roughly as many warts.
IMAP's complexity is not a fault of IMAP, it's a necessary function of
its complex goal... or so I think. I'm open to explanations of why the
protocol is 'baroque', however.
I'm not adverse to the argument that IMAP is superior to NNTP for
reading clients in at least some situations.
Perhaps most importantly, clients for which IMAP support is necessary
for other reasons.
1. It's possible right now. 2. It makes sense in some cases. Shouldn't
that add up to "the protocol and message format shouldn't break it"?
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,
Well, implementing IMAP sure beats implementing IMAP+NNTP ;)
but at this point that's kind of irrelevant given the quantity of
software that speaks it.
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.
I had better reasons, but it's rather off-topic.
--Arnt