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. _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
