Re: [imap5] Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

On Mon, Feb 13, 2012 at 10:55:26AM -0800, Mark Crispin wrote:
> I will say this once. Then I will go back to rolling on the floor laughing
> at the extremely naive things that certain individuals post here.

Go for it.  I said the comments of haters who want to hate were
welcome too, and I stand by it.

> On Mon Feb 13 2012 07:20:45 GMT-0800 (PST), Cyrus Daboo wrote:
> >What is more anyone implementing more than one
> >protocol in their client (e.g. IMAP, CalDAV and CardDAV) would only
> >have to implement that once, albeit with some minor differences in
> >regard to how to get protocol specific pieces for registering for
> >notifications.
> 
> This should be self-evident, as is this statement:
> 
> >Frankly, anyone who has a reasonably solid IMAP4 implementation today
> >is going to question the need to work on something new, particularly
> >if that something new brings nothing to the table (and simply fixing
> >interop problems will probably not be seen as something "new").
> 
> The IMAP5 talk is stunning and laughable in two ways. One is it that it
> seeks to make IMAP "simpler". The other is that it seeks to expand its
> scope to be Exchange.

Simpler as in more regular data model, removing the unnecessary
complexity, not the inherent complexity.  I believe there is a
reasonable pool of unnecessary complexity involved in both ends
of IMAP which isn't inherent in the task of viewing and managing
email, but is instead caused by the layers of protocol on top -
both the irregular syntax of the different layers, and the
MSGNO model with its artifacts like 'UNSEEN' which don't match
the way in which email is being presented and managed by existing
clients today.

And then there's the need to support even more parsers and
protocol agents for SIEVE, ACAP, and good old SMTP/Submission,
plus the support headaches involved in firewall issues.  For the
99% case of a client wanting to send an email via the same
infrastructure where it stores its email, a basic submission will
be sufficient.

All of which I've said plenty of times before.  I've even added
xmove and xsend to Cyrus now.  XMOVE is already in use for our
own web interface code, removing all the quota issues we used to
have with the "Delete to Trash" model, and the crazy workarounds
like deleting a small number of messages at a time.  There's a
draft in progress, and I made sure our implementation is compatible
with all the MUSTs.

> Unstated, but evident, is a third aspect: the naive notion that a protocol
> can be replaced without repeating the work that went into the original.
> History shows that the effort in any replacement is quite a bit greater.

I'm expecting to do a lot of work.  I'm not afraid of work.  I'm
afraid of getting so bogged down saying it can't be done that we
waste another 10 years.

> You can't escape that work no matter smart you think you are, or how much
> better your knowledge and tools are.

You can escape the worst parts of the work by using what already
exists, and by not re-inventing every wheel along the way, but by
looking at some of the wheels that are a lot smoother than they
were 20 years ago.

I would prefer to have you involved than sitting on the sidelines
laughing, but I'd prefer to do something than listen to you saying
it can't be done.  Maybe I'll burn out along the way, maybe not.
I'm still going to try.

Bron.