Hacker News Mobile - HTTP Access to Email Stores

[-] rvkennedy 25 days ago link

We're not talking about webmail here, but direct access by HTTP request, either from a website or a desktop/mobile client. Some other relevant links for this:

http://blog.gaborcselle.com/2010/02/how-to-replace-imap.html

http://blog.webhooks.org/2009/02/13/restful-email-over-http/

HTTP has had about 20 years of use, development, testing - culminating in SPDY now, which could get even 40% faster in some cases. I'm not sure I can think of a good reason not to make the switch.

[-] gioele 25 days ago link
> I'm not sure I can think of a good reason not to make the switch.
IDLE? Tagged, out-of-order replies?
You can probably make a SPDY-based protocol that does 99% of IMAP, but HTTP is too limited for current IMAP possibilities.
Reply
[-] Kadin 25 days ago link
I guess I'm not really sold on why this is better than IMAP, which is a protocol that, um, actually exists and you can use today.
Fixing the perceived drawbacks of IMAP would seem to be a more productive goal than trying to produce a competing protocol/standard. (Cf. http://xkcd.com/927/)
Reply
[-] baudehlo 25 days ago link
There's probably more overhead in the request via HTTP than there is via IMAP, to be honest. I can't see any reason to make this switch other than being able to support port 80.
Reply
- [-] justincormack 25 days ago link
  The reason is to write standardized webmail applications and other javascript apps that want to interact with the email universe.
  Reply

[-] elisee 25 days ago link

If we're going to keep moving more and more apps from native to Web-based, I think we're going to see a lot more of this (standardizing an existing service to be accessible over HTTP), since WebSockets can't connect to any raw TCP sockets (and they shouldn't, that would be terrible security-wise) and WebRTC has the same approach: a protocol of its own with its own handshake & rules.

Better that than have everyone builds its own incompatible HTTP / REST API for common services.

I do wonder if there's any big companies like Google which have pledged to support this spec?

[-] foobarbazetc 25 days ago link

How about we get rid of all the MIME/XML stuff and just represent emails as JSON objects?

The end.

[-] Kadin 25 days ago link
Multipart MIME is fairly clever in that it provides a reasonably human-readable fallback for old clients that don't support it. I'd be very wary of throwing that out. One of the benefits of plain-text email is its universality.
The only way I can see that working out would be if MTAs and MUAs negotiated during handshaking to decide on what message format they preferred, and then the MTA translated the message either to traditional RFC 2822 or some other preferred format, which could be JSON or pure XML or whatever.
Reply
[-] pork 25 days ago link
...in UTF8.
Reply
- [-] pjscott 24 days ago link
  Of course. As far as I'm concerned, you'd need a very good reason not to use UTF-8.
  Reply
  - [-] saurik 24 days ago link
    There are severe issues disassociating files from their native character set when you start dealing with east asian languages and the large amount of existing systems that you are dealing with. Forcing everyone in the world to use UTF-8 is not a legitimate option: it's great if you don't already have something more powerful (like MIME), but it should not dismantle existing known/working setups.
    Reply
[-] justincormack 25 days ago link
You could fairly easily add conneg (yuk) or an alternate json representation to the atom feed... Given that the headers are name value pairs it shouldnt be too hard to standardize.
Reply
[-] rue 25 days ago link
JSON is a MIME type.
Reply
- [-] ollybee 25 days ago link
  application/json
  Reply
- [-] itmag 25 days ago link
  Obnoxious, cryptic, and incommunicado?
  Reply
[-] adrianmonk 24 days ago link
If we get rid of MIME, won't we have gotten rid of HTTP?
Reply

[-] jamesu 25 days ago link

Didn't Outlook Express use some sort of DAV HTTP protocol to retrieve email from Hotmail?

[-] 5l 25 days ago link
1.2. Existing Work.
[...]
Microsoft did some early work on HTTP access to email. The Outlook Express client application uses a fully HTTP-based interface to do all mail functions on Exchange mail stores as well as Hotmail. At the time, Hotmail could or did not support IMAP. The Microsoft API uses PROPFIND to list mailbox contents (this mechanism predated Atom by several years).
Reply
[-] balakk 25 days ago link
Exchange also supports WebDAV - Outlook web access uses(d?) it. In fact, this became one of the easiest ways of integrating with Exchange server. Now that Exchange 2007+ has a full web services API, I hear the DAV stuff has been deprecated.
Reply
- [-] yuhong 25 days ago link
  And I don't think it is in Exchange 2010
  Reply

[-] pepijndevos 25 days ago link

I'm not familiar with the IETF process, but it says "Expires: April 27, 2009"

With that said, I've been exploring the concept a while back myself. I tend to think of email as the largest "social" network in the world, and I think it's good to give it a sexy web face, and then extend it.

https://github.com/pepijndevos/Wemail

[-] cmer 25 days ago link

FYI, Context.io does something similar to this. I know a few YC companies use them.

[-] obilgic 25 days ago link

What is the mark up language used for this plain text file? I really like the format of these minimalist 1 page documents.

[-] icebraining 25 days ago link
I don't think there's a language, I believe it's just plain-text that gets marked up by rfcmarkup[1].
[1]: https://tools.ietf.org/tools/rfcmarkup/
Reply
[-] gioele 24 days ago link
The markup is defined in RFC 2629.
Actually I think that the CSS is what is appealing, not the source marked up file.
If you want, you can convert Markdown into RFC 2629 documents with <https://github.com/cabo/kramdown-rfc2629>.
Reply