You'll have to excuse app authors for not turning a blind eye towards the modern APIs that vendors expose.
To have a great standard, you need to have a non-standard predecessor that sets the tone, approach and philosophy and has proven itself out in the wild without the crutch of a standards body mandating its use. In this way "closed" and "open" work hand in hand to form a healthy ecosystem.
Good standards can't materialize in vacuum. "Non-standard" APIs are the fertile soil they grow in. Most of HTML5 was proprietary extensions before they were standardized. In fact, most of HTML has been "vendor specific" before it was standardized (including the <img> tag).
What is the alternative anyway? To "stop re-AOLizing the web" means to stop progress and stick with a horrible email protocol that has seen little improvement since it was created 30 years ago.
EDIT: All right, people are angry because I'm not acknowledging the current version, IMAP4, which was coined in 1993. Sorry, sorry. That makes it a very modern standard. It completely changes everything I said.
The question that should be asked is if not using IMAP gives for this app any edge over not using it? It seems that the answer is no.
This isn't true and it seems you have never used the app, so you don't know if an IMAP implementation doesn't actually have an edge over it.
IIRC, Mailbox actually had the ability to read your emails - some of the features they provided meant their servers had to have access to your inbox. Now, for this to work on IMAP, that meant giving Mailbox your email and password, and for Mailbox to store that in more-or-less plaintext.
Now as an enduser using Gmail, would you prefer that Mailbox stored your password somewhere in us-east-1, or an easily revokable oauth token?
Mailbox only works with Gmail and iCloud Mail. Gmail supports OAuth2.0 [0] while iCloud does not [1,2]. On the other hand, Outlook supports OAuth2.0 [3] and is not supported by Mailbox.
Thus, even if the choice of the authors of Mailbox gave them some edge, it is surely not the one you described.
That, sadly, is why I am not longer an Apple user.
1990-2000, I was an enormous Apple fanatic. I went to user group meetings. I read everything I could get my hands on about their tech.
When I learned to program C/C++ on windows machines at school, I'd come home and re-implement what I had learned using Codewarrior on my Mac.
Then, Jobs's return marked an era of change for change's sake. Apple went from being "different because different is better" to being "different because different is different".
I'm all about progress and improvement but I despise unnecessary and unproductive change.
It would be nice if Google were publishing their protocol as a standard that could be adopted by others, and eventually adopted as a formal standard.
But they don't seem to show much interest in doing so. There are certainly plausible reasons for this that are not simply related to maintaining their market dominance -- it is cheaper and easier to be able to change your protocol whenever and as often as you need to for your business, rather than try to align to interoperability.
So. What options do 'we' have for trying to move things along the process you describe, where proprietary innovation leads to inter-operable standard, when some key 500 pound gorilla players show little interest in doing so (or in some cases arguably an interest in resisting this)?
There are some similarities between the situation with email and that of html and browsers, although some significant differences, but perhaps the relative recent success (relative!) in maintaining interoperable and documented standards in browsers would be useful to compare and contrast. Email does not seem to be heading in that direction at the moment.
The earth was created over 4.5 billion years ago. I think 1986 is looking pretty young.
One of my least favorite arguments on HN goes like this: foo is old. Full stop. Entirety of argument. As if by virtue of being "old" (definition varies) it should be obvious to everyone that it's not as suitable as whatever thing popped up overnight.
How about this: There are use cases in 2014 that are not covered by a standard built in 1986. As such, to accommodate these things, people have made incompatible extensions to the format, making interoperability very difficult. As such, we need to standardize the way we do these expanded things, whether we put some formal extensions to IMAP or we replace it.
My point was that old is not a cheap way to boost your argument. TCP is also old. So? A list of reasons why it doesn't work would be more convincing. IMAP works.
Understood. Saying "old" is an invalid argument, even among people who are supposed to understand the context. But comparing IMAP to Earth is very valid. It's a marvel of rational thought. You must be very popular.
Everyone who uses IMAP knows its weaknesses. I'm not going to write a book here. It's very, very slow; it has bizarre choices - I still don't understand why I need to delete my message, and then delete the deleted message; it doesn't support now commonplace modern features like tags; its push extension is so naive and resource taxing, companies just implement their own, even when otherwise trying to use IMAP.
But just being slow is an argument enough. I use a few email clients, only one client uses IMAP, and my stomach curls into a ball every time I open it, because I know it'll be synching forever. Even if IMAP being old is a poor argument, me getting old while waiting for it synching, sure is.
Comments
IMAP was created in 1986.
You'll have to excuse app authors for not turning a blind eye towards the modern APIs that vendors expose.
To have a great standard, you need to have a non-standard predecessor that sets the tone, approach and philosophy and has proven itself out in the wild without the crutch of a standards body mandating its use. In this way "closed" and "open" work hand in hand to form a healthy ecosystem.
Good standards can't materialize in vacuum. "Non-standard" APIs are the fertile soil they grow in. Most of HTML5 was proprietary extensions before they were standardized. In fact, most of HTML has been "vendor specific" before it was standardized (including the <img> tag).
What is the alternative anyway? To "stop re-AOLizing the web" means to stop progress and stick with a horrible email protocol that has seen little improvement since it was created 30 years ago.
EDIT: All right, people are angry because I'm not acknowledging the current version, IMAP4, which was coined in 1993. Sorry, sorry. That makes it a very modern standard. It completely changes everything I said.
Progress for the sake of progress is not progress.
The question that should be asked is if not using IMAP gives for this app any edge over not using it? It seems that the answer is no.
This isn't true and it seems you have never used the app, so you don't know if an IMAP implementation doesn't actually have an edge over it.
IIRC, Mailbox actually had the ability to read your emails - some of the features they provided meant their servers had to have access to your inbox. Now, for this to work on IMAP, that meant giving Mailbox your email and password, and for Mailbox to store that in more-or-less plaintext.
Now as an enduser using Gmail, would you prefer that Mailbox stored your password somewhere in us-east-1, or an easily revokable oauth token?
This doesn't make sense.
Mailbox only works with Gmail and iCloud Mail. Gmail supports OAuth2.0 [0] while iCloud does not [1,2]. On the other hand, Outlook supports OAuth2.0 [3] and is not supported by Mailbox.
Thus, even if the choice of the authors of Mailbox gave them some edge, it is surely not the one you described.
[0] https://developers.google.com/gmail/xoauth2_protocol [1] http://stackoverflow.com/questions/18649352/is-there-an-iclo... [2] http://www.iphonehacks.com/2014/01/apps-ask-icloud-password-... [3] http://msdn.microsoft.com/en-us/library/dn440163
That, sadly, is why I am not longer an Apple user.
1990-2000, I was an enormous Apple fanatic. I went to user group meetings. I read everything I could get my hands on about their tech.
When I learned to program C/C++ on windows machines at school, I'd come home and re-implement what I had learned using Codewarrior on my Mac.
Then, Jobs's return marked an era of change for change's sake. Apple went from being "different because different is better" to being "different because different is different".
I'm all about progress and improvement but I despise unnecessary and unproductive change.
What you say makes sense.
It would be nice if Google were publishing their protocol as a standard that could be adopted by others, and eventually adopted as a formal standard.
But they don't seem to show much interest in doing so. There are certainly plausible reasons for this that are not simply related to maintaining their market dominance -- it is cheaper and easier to be able to change your protocol whenever and as often as you need to for your business, rather than try to align to interoperability.
So. What options do 'we' have for trying to move things along the process you describe, where proprietary innovation leads to inter-operable standard, when some key 500 pound gorilla players show little interest in doing so (or in some cases arguably an interest in resisting this)?
There are some similarities between the situation with email and that of html and browsers, although some significant differences, but perhaps the relative recent success (relative!) in maintaining interoperable and documented standards in browsers would be useful to compare and contrast. Email does not seem to be heading in that direction at the moment.
The earth was created over 4.5 billion years ago. I think 1986 is looking pretty young.
One of my least favorite arguments on HN goes like this: foo is old. Full stop. Entirety of argument. As if by virtue of being "old" (definition varies) it should be obvious to everyone that it's not as suitable as whatever thing popped up overnight.
How about this: There are use cases in 2014 that are not covered by a standard built in 1986. As such, to accommodate these things, people have made incompatible extensions to the format, making interoperability very difficult. As such, we need to standardize the way we do these expanded things, whether we put some formal extensions to IMAP or we replace it.
That's quite insightful to compare a 1986 network protocol to a 1986 planet, thank you for enlightening me.
Now I feel justified comparing a 1986 network protocol to a 1986 pizza. Would you take a bite?
My point was that old is not a cheap way to boost your argument. TCP is also old. So? A list of reasons why it doesn't work would be more convincing. IMAP works.
Understood. Saying "old" is an invalid argument, even among people who are supposed to understand the context. But comparing IMAP to Earth is very valid. It's a marvel of rational thought. You must be very popular.
Everyone who uses IMAP knows its weaknesses. I'm not going to write a book here. It's very, very slow; it has bizarre choices - I still don't understand why I need to delete my message, and then delete the deleted message; it doesn't support now commonplace modern features like tags; its push extension is so naive and resource taxing, companies just implement their own, even when otherwise trying to use IMAP.
But just being slow is an argument enough. I use a few email clients, only one client uses IMAP, and my stomach curls into a ball every time I open it, because I know it'll be synching forever. Even if IMAP being old is a poor argument, me getting old while waiting for it synching, sure is.
It is slightly stupid to pretend that IMAP was created in 1986 and then never changed.