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 delusional.
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 clever done on one client isn’t reproduced on any other client. And if I don’t have a client on my current computer for GMail, I can use a web browser, and still get all the features of the server. I use the web gmail interface for everything anyway, because it’s better than any GUI client I’ve got.
I dont know - this guy makes for pretty convincing arguments on why email should be done right on the server rather than the client. Which effectively means a new protocol.
If not designed very carefully, though, it can reduce the user's ability to view things as they like them. With the current status quo of mailservers not handling message threading and such, I can choose a client that handles it how I want. If the server is doing it, it had better either do it how I want it, or provide some way to customize what it's doing.
(For example, I don't like gmail's flat "conversation" view; I much prefer a "threaded conversation" view, like classic Usenet readers, or HN discussions.)
reMAP claims to treat conversations as first class objects. Given suitable APIs on top, I think you could build different views on different email clients.
I think what is meant by a new protocol and server innovation is a change in the data model. I do not believe they are going to dictate views.
Yes, we could be happy with the status quo. But I do believe that one of the things that's holding up innovation around email is the lack of easy access to data. Proposed exercise: Write a script that downloads and displays your Twitter feed. Then write a script that downloads and displays your email. The email exercise will take you an order of magnitude longer.
Spam filtering isn't the problem you make it out to be. I get more spam in my Facebook inbox (mostly viruses) than in Gmail. If you're hosting you're own email or are using a sucky provider, that's a different story.
Email will be hard to replace long-term anyway. I doubt your bigcorp employer really going to let you send work-related Facebook messages. IM is a fundamentally different protocol with different use cases (think async vs. sync, fax vs. phone).
IMAP and MIME are hard because there is a higher level of information that is available. Can you attach an archive over Twitter (not link to but attach)? Can you send HTML? They are not the same thing. If you want something really simple your code will be simple. If you want more use cases than "i can haz cheeseburger" then you need more expressive power and more complexity.
But to pretend that the reason facebook and IM are replacing email is IMAP (and not, y'know, spam) is borderline delusional.
As is believing that it's about spam (or probably believing it all, for that matter, but let's stay on topic).
I don't understand people bitching about spam in 2010. I have probably a dozen email addresses that I publish all over the web and I get maybe one spam message a month. I get way more "spam" through Twitter than I do through my email.
I don’t understand people declare the spam problem solved.
I have had false positives with every single spam filter I have tried. This is unacceptable when running a business, and if we manually have to double-check hundreds of spams each day, what is the point of the filter?
Additionally we spend hours each week working with users who do not receive our emails because of spam filters unknown to them (many believe the fault is ours).
> if we manually have to double-check hundreds of spams each day, what is the point of the filter?
It's faster to scan a list of subject lines and senders than to look at the contents of an email, which is faster than actually deleting it. So verifying that the spam filter sorted your emails correctly is faster than sorting every message yourself.
It seems like the key is to work on top of an interface that does all the dirty work of negotiating with IMAP for you, such as the lisp mel-base library. Then you really don't care how messy imap might be, as you can build on top of it at increasing levels of abstraction.
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.
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.
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 delusional.