Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Replace IMAP

gaborcselle.com

Post reply on HN
Print view View original

11–20 of 62 posts

Re: How to Replace IMAP

#11

Post by ajross »

gduffy wrote: post #7
ajross wrote: post #2

Not to spend too much effort defending IMAP (which does, to be fair, kinda suck) but... come on. It's not that hard. It works just fine, enjoying pervasive support with very high quality clients and servers available freely on essentially all platforms. A new protocol would be ... prettier, I guess. But to pretend that the reason facebook and IM are replacing email is IMAP (and not, y'know, spam) is borderline delusi…

This is not about making it easier to write email clients or servers, it's about making it easier to write email apps. Currently, you either have to write a plugin for an email client or interact with IMAP directly. Opening up email to mainstream developers means ditching IMAP/MAPI/etc as the API.

And again, I don't see why that's such a huge improvement. IMAP is clunky and weird, but it's not rocket surgery. If there was a huge market opportunity for someone to write custom mailoid gadgets using IMAP, clearly it would have been done already.

A better protocol will only be "better", analogous to, say, the Mac (c. 1990) being better than Windows 3.1. While true, compatibility pressures aren't going to allow someone else into the market simply for being "better". You have to be transformative, and this isn't.

And in any case what's killing email isn't the lack of apps, it's the lack of authentication and moderation.

Re: How to Replace IMAP

#12

Post by neilc »

gduffy wrote: post #7
ajross wrote: post #2

Not to spend too much effort defending IMAP (which does, to be fair, kinda suck) but... come on. It's not that hard. It works just fine, enjoying pervasive support with very high quality clients and servers available freely on essentially all platforms. A new protocol would be ... prettier, I guess. But to pretend that the reason facebook and IM are replacing email is IMAP (and not, y'know, spam) is borderline delusi…

This is not about making it easier to write email clients or servers, it's about making it easier to write email apps. Currently, you either have to write a plugin for an email client or interact with IMAP directly. Opening up email to mainstream developers means ditching IMAP/MAPI/etc as the API.

You rarely need to use IMAP directly, though: most email apps are fine using a library that manages the details of the IMAP protocol under the covers, and presents a more sane interface.

Re: How to Replace IMAP

#13

Post by mrduncan »

gaborcselle wrote: post #10
mrduncan wrote: post #4

The description for #8 sounds more like long polling to me. For push email, I'd envision something like registering a location to send notifications to (web hooks).

Yeah, it is long polling. I could be misinformed, but isn't the problem with web hooks that you might not have ports open and could be behind a firewall?

Yea, I'd say long polling is probably a better solution in this case than web hooks since clients (likely) could be behind firewalls, NAT, and be going on and off line relatively often. Sorry, the title and description on that one just threw me off a bit - I think you chose the best option though.

Re: How to Replace IMAP

#15

Post by gridspy »

Joe_Bananas wrote: post #14

Ah, yes. A new email scheme that would require us to replace all clients and servers in one fell swoop. I can see that taking off.

All it requires is a major server (i.e gmail) providing it as an option and a major client (say a iPhone email app) supporting that option.

Re: How to Replace IMAP

#16

Post by jwhitlark »

My responses to your Design Outline.

1. I'm not convinced that http/https is the best protocol. I agree that it's the defacto standard, but if you're going to go through this, there might be a better way. (Push, in particular, is a problem).

2. Stateless is wonderful, agreed.

3. I agree with JSON over XML, but what about binary data? That is the weakest part of JSON, in my opinion.

4. I like where you're going with this, but I'm not sure this is the exact right way to handle it.

5. Agreed.

6. how about SHA-1 hashes of content? Done properly, that would eliminate any duplicate messages, and could make it very easy to include other messages. This might also allow content to be transfered between accounts only once, dropping bandwidth and speeding delivery.

7. Don't know enough about MIME to comment.

8. According to your comments on this page, you're referring to long polling. I agree that this use case needs to be addressed, but I'm not sure that this is the way to do it. Perhaps multiple options here?

9. Good idea, but do you think that stemming/language differences is going to be a problem? What about other types of content? attachments?

The biggest thing missing from this list is some sort of Public Key Encryption. Anyway, it looks like a good start.

Re: How to Replace IMAP

#17

Post by beh »

tdmackey wrote: post #5

First the solution doesn't really fulfill all of imaps use cases (especially push mail) but that is unimportant. What is important is that the IMAP protocol isn't difficult, and I don't think that is what limits "email innovation." It is more so that it has been around since the 70s and email clients haven't been able to remove themselves from their past. It isn't the protocol limiting them from moving forward, it is…

I'm very hopeful for Letters, a project just taking off under the leadership of some pretty big names: Gruber, Rands, Brent Simmons. They're hoping to collectively create a "lean and programmable IMAP email client, with plugin and automation APIs, designed for developers and power users." While still sparse and very early-stage, their vision document is ambitious: http://pastie.org/785269 If something comes from this, it'll definitely be a step forward to modernize email clients.

Project wiki: http://letters-wiki.heroku.com/

Re: How to Replace IMAP

#18

Post by JoachimSchipper »

This is a collection of the author's favourite technologies/gripes, not a useful proposal. A large number of errors can be found by considering that it'll have to talk SMTP on the back end.

I'll only point to some "highlights".

OAuth isn't nearly secure enough (http://hueniverse.com/2009/04/explaining-the-oauth-session-f...) for your e-mail (which, don't forget, gives access to everything via password resets). Let's just ignore the part about third-party access.

Encoding everything as UTF-8 is nice, but breaks the first time some idiot mail client puts Shift-JIS encoded Japanese in the Subject: field. Without any charset marker, obviously. (This goes right back to the "where does the mail come from?" issue.)

IMAP has a THREAD extension (solving #4), a SEARCH extension (solving #9 and parts of others), and all sensible servers support IDLE (http://en.wikipedia.org/wiki/IMAP_IDLE). It also supports downloading MIME parts separately, solving the part of #7 that can actually be solved (again, you'll have to accept mail.)

Re: How to Replace IMAP

#19

Post by tedunangst »

sandGorgon wrote: post #6
ajross wrote: post #2

Not to spend too much effort defending IMAP (which does, to be fair, kinda suck) but... come on. It's not that hard. It works just fine, enjoying pervasive support with very high quality clients and servers available freely on essentially all platforms. A new protocol would be ... prettier, I guess. But to pretend that the reason facebook and IM are replacing email is IMAP (and not, y'know, spam) is borderline delusi…

http://jerakeen.org/notes/2010/01/yay-more-email-clients/ The Android GMail client is a perfect example of what a client looks like in this world. It talks to the (secret / private) GMail API, it does offline mail reading, and queues actions so you can archive / filter / whatever mails while offline and it’ll push changes later. You can read and write mail. It doesn’t try to do anything clever, because anything cleve…

I started using this new "mail on the server" protocol way back in 2000, but back then we called it SSH. :)

Re: How to Replace IMAP

#20

Post by there »

gridspy wrote: post #15
Joe_Bananas wrote: post #14

Ah, yes. A new email scheme that would require us to replace all clients and servers in one fell swoop. I can see that taking off.

All it requires is a major server (i.e gmail) providing it as an option and a major client (say a iPhone email app) supporting that option.

oh, that's all?

it'll require an RFC or some other kind of standard, which will take a long time to finalize. then someone will have to write a reference spec server and client, then "real" versions in "real" languages, then get them both to the stability, security, and scalability of current imap clients and servers. then once big email providers (isps, google, etc.) start supporting it on the server end (gotta factor in all those different operating systems, authentication systems, storage systems, etc.), popular clients can support it. then work out all of the minor implementation details that some servers or clients get wrong (i think almost every smtp and pop3 server has hacks in it to support the stupid things outlook express does wrong), and then once everyone complains long enough, the iphone will finally get support for it (while a small but vocal minority shouts that android already supports it).

there is a reason why smtp, imap, pop3, dns, http, and all of the other core internet protocols are still around after 20 years and it's not because there aren't any faults in any of them.

Post reply on HN