84 lines
3.3 KiB
Plaintext
84 lines
3.3 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Thu Feb 9 03:24:11 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:47 2018
|
|
Subject: [Imap-protocol] Re: [imap5] Designing a new replacement protocol
|
|
for IMAP
|
|
In-Reply-To: <4F337E61.5040702@qbik.com>
|
|
References: <1328732126.32086.140661033971485@webmail.messagingengine.com>
|
|
<201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com>
|
|
Message-ID: <20120209112411.GB29734@launde.brong.net>
|
|
|
|
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.
|
|
|