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

[Bron Gondwana <[e-mail]>]

On Thu, Feb 09, 2012 at 09:05:53PM +1300, Adrien de Croy wrote:
> 
> Whilst HTTP could certainly be used to put together an email system,
> I don't think it would perform well enough to replace existing
> protocols on desktops.
> 
> The main issues I see are:
> 
> * updates.  Would need to poll or use long polling to get real-time
> updates (e.g. notification of incoming mail).

Yes - long polling or "out of band" notification systems.  We have
an HTTP protocol defined kind of "on top of" IMAP plus our own
extensions here at FastMail/Opera (mail.opera.com if you want to
play with it)

We are currently using EventSource to notify the client that
"there is something new", after which the client queries to
find what's updated.

This is possible to be efficient because we use a single counter
for uidvalidity and a single counter for highestmodseq across the
entire user's folders - so any change to uidvalidity means the
folder list needs refreshing, and any change to highestmodseq
means the message view needs checking.

Combined with efficient "what's changed in this view since my
previous modseq value" queries, it's very bandwidth efficient.

> * slow.  Gut feel based on 17 years writing http proxies is that it
> would be too slow

Not really actually - so long as you can query multiple things in
a single "transaction"

> * complex.  In order to reduce round-trips, you'd have to do many
> things in a single transaction, which would create complexity issues
> in the server and client

But here's the rub.  Yes, complex.

> * protocol bloat.  if you think IMAP is bloated, try HTTP.
> * fundamentally an off-line style protocol for mail, which has
> strong incentives to be online (esp for in-office use).

Mostly facebook's "live feed" is plenty fast enough.  People are
doing all sorts of close-enough-to-real-time stuff on top of HTTP.
It doesn't mean it's the right choice, but I wouldn't dismiss it
out of hand either.

> I think it would also be very problematic in the wild, since any
> http intermediary would feel entitled to mess with traffic.  E.g.
> heuristic caching, intercepting proxies etc.

That's a problem for sure.  Mind you, proxyability is high on my
list of goals.  Immutable stuff should be cachable.

> It's almost too ubiquitous.  Everyone and their dog thinks they know
> how http works.  It's not strictly-enough defined, and has a LOT of
> optional features which aren't relevant for mail (e.g. content
> negotiation).  Interop in http is already problematic, but start
> getting people writing mail servers in php etc, and see what starts
> to happen.  I think it would be a nightmare.

Like IMAP then, except only their dogs actually understand it ;)

Good enough tests should, in theory, allow people to write their
servers in PHP if they want to.  Why you would choose to write in
PHP, I'm not sure... but still.  It takes all types.

Bron.