On 10/02/2012 12:24 a.m., Bron Gondwana wrote:
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)
if you compare the overhead / complexity in setting up the poll (on a
separate connection), and re-sending the poll request each time it's
completed by the server (or timed out by an intermediary etc), it's a
particularly inelegant and wasteful way to get a notification.
It's done this way in HTTP because that's the only way to do it, but
let's face it, it's a fairly ugly hack.
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.
it might seem quick enough for a human, but not all mail clients are
humans. E.g. EDI systems etc.
I wouldn't dismiss HTTP out of hand either, but I would take some
convincing, and the work that would be required to specify the requests
and responses (would you use SOAP-RPC?) would be not much less (if any)
than that required to do a nice slim efficient and blindingly quick
specialised protocol.
In fact, since mobile devices are going to probably be the primary
agents for mail, we really should be looking at a binary protocol?
Just not ASN.1 BER :)
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.
caches impose their own beliefs on what is cachable and for how long.
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.
it sure does :)
Adrien
Bron.
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
