They do this for good reason -- dealing with the various dysfunctional IMAP implementations out there makes your product look lousy and costs alot of time & treasure to support. When some squeaky wheel blogger with a screwed up IMAP server writes a ten page rant about why you suck, nobody gets the other side of the story.
I had a relative who ran a business that only served customers in Manhattan. Brooklyn? Jersey? Not interested.
Why? His competitive edge was understanding his customer base cold. He knew what companies were in what buildings, and all of the trivia about different neighborhoods and streets that let him win bids and save time.
Thank you. As soon as I read "open, well-documented and well-understood platform like email" I laughed, but only because what I really wanted to do was cry. I assume that the author had never had the misfortune of trying to build a MUA or MTA that had to be widely compatible with other implementations.
If you have the option of talking only to Gmail and still being successful? Yes.
I think it's high time to revise the IMAP/SMTP interface for clients anyway; the JMAP spec that fastmail has put together is pretty interesting: http://jmap.io/
A really good way to encourage innovation in the mail client space might be to write a proxy server for JMAP (or something similar) to a legacy IMAP/SMTP setup, and hide all the legacy IMAP/SMTP issues inside the proxy so that building a client anyone can use could actually be fun.
I'm planning to chat to people at OSCON later this month about JMAP, and we're making a big push at FastMail to do exactly what you suggest - build a proxy that can wrap any IMAP/SMTP setup.
It won't be quite so fast as running a server that can support JMAP natively (we also plan to build an open-source JMAP server on top of the Cyrus IMAPd that we use internally) - but it will bridge the gap :)
Comments
They do this for good reason -- dealing with the various dysfunctional IMAP implementations out there makes your product look lousy and costs alot of time & treasure to support. When some squeaky wheel blogger with a screwed up IMAP server writes a ten page rant about why you suck, nobody gets the other side of the story.
I had a relative who ran a business that only served customers in Manhattan. Brooklyn? Jersey? Not interested.
Why? His competitive edge was understanding his customer base cold. He knew what companies were in what buildings, and all of the trivia about different neighborhoods and streets that let him win bids and save time.
Thank you. As soon as I read "open, well-documented and well-understood platform like email" I laughed, but only because what I really wanted to do was cry. I assume that the author had never had the misfortune of trying to build a MUA or MTA that had to be widely compatible with other implementations.
If you have the option of talking only to Gmail and still being successful? Yes.
Exactly -- I worked on IMAP related nonsense for about 18 months -- it is a special, broken type of hell.
Then, god forbid it works well enough to get a message from the server. Now you have to deal with trash like quoted printable, which is neither.
I think it's high time to revise the IMAP/SMTP interface for clients anyway; the JMAP spec that fastmail has put together is pretty interesting: http://jmap.io/
A really good way to encourage innovation in the mail client space might be to write a proxy server for JMAP (or something similar) to a legacy IMAP/SMTP setup, and hide all the legacy IMAP/SMTP issues inside the proxy so that building a client anyone can use could actually be fun.
I'm planning to chat to people at OSCON later this month about JMAP, and we're making a big push at FastMail to do exactly what you suggest - build a proxy that can wrap any IMAP/SMTP setup.
It won't be quite so fast as running a server that can support JMAP natively (we also plan to build an open-source JMAP server on top of the Cyrus IMAPd that we use internally) - but it will bridge the gap :)