9 ms·

Making Google’s CalDAV and CardDAV APIs available for everyone

253 points by Zikes 13y ago

deleted 13y ago
[deleted]
mwfunk 13y ago
This is pretty outstanding on Google's part. Thank you to whoever made this happen.
- Matt_Cutts 13y ago
  If you hear people saying that Google closed CalDAV (an open standard for calendar info), please point them to the blog post at http://googledevelopers.blogspot.com/2013/06/making-googles-caldav-and-carddav-apis.html http://googledevelopers.blogspot.com/2013/06/making-googles-... to let them know CalDAV is remaining open and that Google is opening up CardDAV access (used for contact info) to everyone too. I'm glad that Google is doing this.
  - Andrex 13y ago
    This is so awesome to see. I really want to thank the people involved in this decision, do you know who those might be Matt?
    - mayank 13y ago
      I'm sure Googlers will point them to this thread, so feel free to thank them here :)
    - Matt_Cutts 13y ago
      There were a bunch of people, including regular Googlers from around the company who asked about this. Personally, I'm most grateful to the core group on the team that listened to both external and internal feedback and then went back to see how they could make things better. I understand and respect if those folks want their privacy, but I thought it was really great to see them not only change their mind, but ask about how to push more on openness in this area. At this point, Google supports open standards for calendar, contacts, and email. It's great to see CardDAV open up to everyone.
      - mindcrime 13y ago
        Matt, do you have any insight into whether or not there's even any internal discussion within Google about revisiting the XMPP issue regarding Hangouts, and/or publish a spec for their new protocol? Of course I totally understand if you either don't know, or aren't allowed to comment. Just curious if it's something that's even a point of discussion or if everybody considers the issue closed, done, over, fini...
        Matt_Cutts 13y ago
        It's safe to assume that for anything that's even mildly controversial externally, there's a ton of internal discussion as well. Usually the internal discussion is even more passionate than the external discussion. I'm an advocate for the idea that Google wants to compete on a level playing field, which leads directly to the fact that I believe Google should also support open standards and interoperability. That means that any time we aren't doing that, we need to have a really, really good reason for it. That said, after a ton of discussion about XMPP internally, I understand the team's decision and their reasons.
        deleted 13y ago
        [deleted]
        mindcrime 13y ago
        Thanks for sharing. It's good to know that there is (probably) at least some discussion about this stuff. If anything, maybe you could give them a little nudge in the direction of releasing a detailed spec (and a reference implementation) of the new Hangout protocol? :-)
  - pyre 13y ago
    | Google is opening up CardDAV CardDAV was accessible, but it was not documented. Some Googling could get you some archived mailing list threads where people posted the 'secret' URLs[1]. Even then, I couldn't get responses to all of the requests defined in the RFC. I remember getting a listing of supported request types from the server, but not all of them worked. Also "All Contacts" was not accessible. "My Contacts" was the only address book accessible to CardDAV. For reference, I've put the stuff I was playing around with on Github: https://github.com/bsandrow/scratchpad-google-carddav https://github.com/bsandrow/scratchpad-google-carddav [1] I say secret because those mailing list posts were the only references I could find to them, so I don't know how they were obtained.
  - Serow225 13y ago
    That's a great decision on their part. However I really hope they reconsider the removal of ActiveSync support aka Google Sync. Totally anecdotal, but my wife is not a fan of the official Gmail iOS client which is their current solution for push email, and IMAP works OK with the stock Mail app for her except for the lack of push. I'd be OK with paying for Google Apps account to get ActiveSync back, except that you can't do that with a Gmail address.
    - mitchty 13y ago
      I thought the reason for the activesync/exchange shutoff is that it had to be licensed. aka that google paid microsoft for being able to use it? If so maybe it isn't worth it due to a licensing increase or just not used by many people (for some value, google is crazy about numbers guiding decisions).
    - kllrnohj 13y ago
      Gmail's IMAP supports the IMAP push extensions. I don't know if Apple's Mail app supports them or uses them, but just because it's IMAP doesn't mean it isn't push.
      - Serow225 13y ago
        Thanks, I didn't even know there was such as thing as P-IMAP. So I guess it's up to Apple to add support for this to the Mail app huh?
        Aloha 13y ago
        I think the iPhone does support it.
        danudey 13y ago
        OS X's mail client supports IMAP push as well.
deleted 13y ago
[deleted]
rasterizer 13y ago
Not merely a reinstatement: OAuth 2.0 as well.
pkulak 13y ago
Does this mean there will be a way to sync Google contacts on iOS again?
- Zikes 13y ago
  That seems to be the implication of the new CardDAV API.
- Shooti 13y ago
  You could already do this in iOS by going into Settings -> Mail,Contacts, Calendars -> Add Account -> Other -> Add CardDAV and entering your Google account user/pass. This makes no difference whatsoever.
  - Zikes 13y ago
    The blog post says that both APIs will be getting OAuth 2.0, though. If iOS doesn't support that protocol for CardDAV, doesn't that mean that this may actually break it?
    - dunham 13y ago
      I wouldn't be surprised if they require OAuth2, but I'm guessing they'll grandfather in clients with lots of users (like Apple), until they can switch over. I've suspected for a while that their issue with CalDAV was security. Currently you need to store a plaintext copy of the user's password to do caldav. The only copy of my google password in my iOS keychain is for caldav. Since Google Authenticator stores its key in the same keychain, both auth factors are there. I'd kinda wished they'd propose fixes for caldav, rather than just drop it. Now it sounds like they're doing that.
      - Zikes 13y ago
        I know that Google Authenticator supports application-specific passwords for applications that don't support OAuth 2.0, but I'm not familiar with Google's use of application-specific passwords outside of the context of Google Authenticator. Perhaps that could be enabled for all users regardless of 2FA activation, and be made available for use with these and other applicable APIs?
avel 13y ago
Good move. Now please clarify what will happen with XMPP in Hangouts!
prg318 13y ago
While this is nice, it would be great to see native CalDAV/CardDAV support in Android without having to use non-free third party adapters that are not even feature complete [1] [2]. [1] https://play.google.com/store/apps/details?id=org.dmfs.caldav.lib https://play.google.com/store/apps/details?id=org.dmfs.calda... [2] https://play.google.com/store/apps/details?id=org.dmfs.carddav.Sync https://play.google.com/store/apps/details?id=org.dmfs.cardd...
- prg318 13y ago
  I'm not quite sure why I'm getting heavily downvoted. Does anyone else find it odd that Google is supporting CalDAV/CardDAV on their servers but not on their operating system? Or am I being downvoted for being critical of Google?
  - Zikes 13y ago
    I think it's a pretty fair criticism.
  - callahad 13y ago
    Your comment is of topical interest, but it doesn't seem to be terribly relevant to the announcement at hand. I suspect that's where the downvotes came from, though I've not personally voted either way.
  - vetinari 13y ago
    What is the use case? For service provided by Google, use the supplied sync adapter. Yes, it is not CalDAV/CardDAV, but a whole google account package. For third-party services, use adapters supplied by these third parties. The third party adapters have the ability to be first class citizens in Android, but to make them so is up to their authors.
    - prg318 13y ago
      The use case is exactly what you have described: third party services. If one wants to run a Calendar service, open standards allow them to use a published standard protocol (CalDAV in this case) that clients can use regardless of platform. Most desktop calendar software (and even iOS AFAIK) support CalDAV and it seems that Google has cleverly omitted CalDAV support from their mobile OS, locking Android users into using Google Calendar with no other option. That being said, there's nothing stopping someone from writing a proper CalDAV/CardDAV adapter and releasing it on the Play Store. But with all of the claims of Google supporting open standards I was highly surprised to see that Google neglected to implement CalDAV/CarDAV in Android.
shmerl 13y ago
Good decision. Can Google also revert their decision to drop XMPP federation with their Hangouts now?
- MikeKusold 13y ago
  This has been beaten to death already. Hangouts supports way more functionality than XMPP calls for. In order to create a cohesive product, you can't have half your features not work with 3rd party clients that people might use. I think a better plea would be for Google to release Hangouts as a protocol.
  - shmerl 13y ago
    > Hangouts supports way more functionality than XMPP calls for. While federating with XMPP they can expose only a subset. > I think a better plea would be for Google to release Hangouts as a protocol. I'm only for it. Which doesn't preclude the option above. Additionally, Google can extend XMPP if it lacks what they need.
    - Zikes 13y ago
      I would love to see classic Google Talk return, with status settings/messages, the ability to see if contacts are online, etc., however I'm not so sure extending XMPP is the way to go. It's my understanding that XMPP is an exceptionally verbose protocol, built on XML. It's great for interoperability, but there are better formats available now, including JSON and msgpack, which would be much more ideal for mobile IM.
      - shmerl 13y ago
        XML can be compressed: http://xmpp.org/extensions/xep-0138.html http://xmpp.org/extensions/xep-0138.html JSON isn't less verbose by the way. It also lacks namespaces, so I doubt it can help for a complex and extensible protocol.
      - stuaxo 13y ago
        True, there are loads of libraries to support XMPP on various platforms though.
mwcampbell 13y ago
I'm glad Google made CardDAV available and decided not to restrict CalDAV, at least for now. However, I wonder how long it will continue to support these standards, especially for users of the free services. Supporting these standards might not be directly in Google's best interest, since the more thoroughly Google supports task-specific protocols such as CardDAV, CalDAV, and XMPP, the fewer opportunities it has to present ads. So it may still be good for users to think about moving to services where the user is actually the customer.
- jmillikin 13y ago
  In all cases the user is the customer. Some customers pay with real currency (e.g. those who have enterprise accounts), others pay by loaning a few thousand pixel-seconds to advertisers. It's very much in Google's interest to encourage task-specific protocols, because they can be attached to subscriptions, and subscriptions are denominated in real currency. If Jane Smith knows that GAE has good support for syncing her calendar to her iPhone, she's more likely to use it as her company's email/calendar/documents provider.
- jkn 13y ago
  Could you be more specific? AFAIK there are no ads in Google Talk/Hangouts, Calendar and Contacts. Google is known for making the vast majority of its money from ads, but definitely not for putting ads in all of their products. Even if they did show add in these products, how does that relate to supporting standards as alternative means of accessing your data? Like in Gmail, which shows ads in the web interface but also supports POP and IMAP.
NameNickHN 13y ago
This is good news, I guess, but I'll play the pessimist and ask: "How long will this commitment hold?
zmmmmm 13y ago
While this is great and I sincerely congratulate Google for it, I still find the wording slightly disturbing. They say they were going to close down the API because only "a few large developers" were using it. Then that since they've heard from developers about a lot of "use cases" they've decided to change their mind. For me, openness is a relatively unconditional principle. You do it because it is a virtue in and of itself. To hear that we need to spell out specific use cases to justify something being open seems to indicate that Google slightly misses the point. Google shouldn't have to like our reasons for wanting things open. Google should have to justify why they are closed. Indeed, it's in the most unfriendly situations when the openness matters (ie: we want to get our data out of Google and move away from Google services). So while I'm happy to hear this, and I know I'm picking nits here, it still doesn't quite feel like the "old" Google that really made a principle out of these things.
- dragonwriter 13y ago
  > While this is great and I sincerely congratulate Google for it, I still find the wording slightly disturbing. They say they were going to close down the API because only "a few large developers" were using it. Incorrect. They said they were going to make it a whitelisted, by-request, partner-only API for that reason, rather than that they were going to close it down. There is a fairly significant difference. > For me, openness is a relatively unconditional principle. You do it because it is a virtue in and of itself. In the real world, few things are unconditional, and while Google has certainly claimed openness as one of its values, Google has never claimed that using open standards is an unconditional principal that is never weighed against other concerns.
- skeletonjelly 13y ago
  I'm thinking they've learnt from mistakes in their past where they've put in a concerted amount of effort to open source something only then to find out nobody wants to use it. Open sourcing it to their current standard requires code cleanup, documentation etc.
- jessedhillon 13y ago
  Google should have to justify why they are closed. This seems like a rather entitled position to take. By what reasoning is Google, a private, for-profit entity, obligated to make anything of this sort available to you?

253 points by Zikes 13y ago

deleted 13y ago

[deleted]

mwfunk 13y ago

This is pretty outstanding on Google's part. Thank you to whoever made this happen.

Matt_Cutts 13y ago
If you hear people saying that Google closed CalDAV (an open standard for calendar info), please point them to the blog post at http://googledevelopers.blogspot.com/2013/06/making-googles-caldav-and-carddav-apis.html http://googledevelopers.blogspot.com/2013/06/making-googles-... to let them know CalDAV is remaining open and that Google is opening up CardDAV access (used for contact info) to everyone too. I'm glad that Google is doing this.
- Andrex 13y ago
  This is so awesome to see. I really want to thank the people involved in this decision, do you know who those might be Matt?
  - mayank 13y ago
    I'm sure Googlers will point them to this thread, so feel free to thank them here :)
  - Matt_Cutts 13y ago
    There were a bunch of people, including regular Googlers from around the company who asked about this. Personally, I'm most grateful to the core group on the team that listened to both external and internal feedback and then went back to see how they could make things better. I understand and respect if those folks want their privacy, but I thought it was really great to see them not only change their mind, but ask about how to push more on openness in this area. At this point, Google supports open standards for calendar, contacts, and email. It's great to see CardDAV open up to everyone.
    - mindcrime 13y ago
      Matt, do you have any insight into whether or not there's even any internal discussion within Google about revisiting the XMPP issue regarding Hangouts, and/or publish a spec for their new protocol? Of course I totally understand if you either don't know, or aren't allowed to comment. Just curious if it's something that's even a point of discussion or if everybody considers the issue closed, done, over, fini...
      - Matt_Cutts 13y ago
        It's safe to assume that for anything that's even mildly controversial externally, there's a ton of internal discussion as well. Usually the internal discussion is even more passionate than the external discussion. I'm an advocate for the idea that Google wants to compete on a level playing field, which leads directly to the fact that I believe Google should also support open standards and interoperability. That means that any time we aren't doing that, we need to have a really, really good reason for it. That said, after a ton of discussion about XMPP internally, I understand the team's decision and their reasons.
        deleted 13y ago
        [deleted]
        mindcrime 13y ago
        Thanks for sharing. It's good to know that there is (probably) at least some discussion about this stuff. If anything, maybe you could give them a little nudge in the direction of releasing a detailed spec (and a reference implementation) of the new Hangout protocol? :-)
- pyre 13y ago
  | Google is opening up CardDAV CardDAV was accessible, but it was not documented. Some Googling could get you some archived mailing list threads where people posted the 'secret' URLs[1]. Even then, I couldn't get responses to all of the requests defined in the RFC. I remember getting a listing of supported request types from the server, but not all of them worked. Also "All Contacts" was not accessible. "My Contacts" was the only address book accessible to CardDAV. For reference, I've put the stuff I was playing around with on Github: https://github.com/bsandrow/scratchpad-google-carddav https://github.com/bsandrow/scratchpad-google-carddav [1] I say secret because those mailing list posts were the only references I could find to them, so I don't know how they were obtained.
- Serow225 13y ago
  That's a great decision on their part. However I really hope they reconsider the removal of ActiveSync support aka Google Sync. Totally anecdotal, but my wife is not a fan of the official Gmail iOS client which is their current solution for push email, and IMAP works OK with the stock Mail app for her except for the lack of push. I'd be OK with paying for Google Apps account to get ActiveSync back, except that you can't do that with a Gmail address.
  - mitchty 13y ago
    I thought the reason for the activesync/exchange shutoff is that it had to be licensed. aka that google paid microsoft for being able to use it? If so maybe it isn't worth it due to a licensing increase or just not used by many people (for some value, google is crazy about numbers guiding decisions).
  - kllrnohj 13y ago
    Gmail's IMAP supports the IMAP push extensions. I don't know if Apple's Mail app supports them or uses them, but just because it's IMAP doesn't mean it isn't push.
    - Serow225 13y ago
      Thanks, I didn't even know there was such as thing as P-IMAP. So I guess it's up to Apple to add support for this to the Mail app huh?
      - Aloha 13y ago
        I think the iPhone does support it.
      - danudey 13y ago
        OS X's mail client supports IMAP push as well.

deleted 13y ago

[deleted]

rasterizer 13y ago

Not merely a reinstatement: OAuth 2.0 as well.

pkulak 13y ago

Does this mean there will be a way to sync Google contacts on iOS again?

Zikes 13y ago
That seems to be the implication of the new CardDAV API.
Shooti 13y ago
You could already do this in iOS by going into Settings -> Mail,Contacts, Calendars -> Add Account -> Other -> Add CardDAV and entering your Google account user/pass. This makes no difference whatsoever.
- Zikes 13y ago
  The blog post says that both APIs will be getting OAuth 2.0, though. If iOS doesn't support that protocol for CardDAV, doesn't that mean that this may actually break it?
  - dunham 13y ago
    I wouldn't be surprised if they require OAuth2, but I'm guessing they'll grandfather in clients with lots of users (like Apple), until they can switch over. I've suspected for a while that their issue with CalDAV was security. Currently you need to store a plaintext copy of the user's password to do caldav. The only copy of my google password in my iOS keychain is for caldav. Since Google Authenticator stores its key in the same keychain, both auth factors are there. I'd kinda wished they'd propose fixes for caldav, rather than just drop it. Now it sounds like they're doing that.
    - Zikes 13y ago
      I know that Google Authenticator supports application-specific passwords for applications that don't support OAuth 2.0, but I'm not familiar with Google's use of application-specific passwords outside of the context of Google Authenticator. Perhaps that could be enabled for all users regardless of 2FA activation, and be made available for use with these and other applicable APIs?

avel 13y ago

Good move. Now please clarify what will happen with XMPP in Hangouts!

prg318 13y ago

While this is nice, it would be great to see native CalDAV/CardDAV support in Android without having to use non-free third party adapters that are not even feature complete [1] [2]. [1] https://play.google.com/store/apps/details?id=org.dmfs.caldav.lib https://play.google.com/store/apps/details?id=org.dmfs.calda... [2] https://play.google.com/store/apps/details?id=org.dmfs.carddav.Sync https://play.google.com/store/apps/details?id=org.dmfs.cardd...

prg318 13y ago
I'm not quite sure why I'm getting heavily downvoted. Does anyone else find it odd that Google is supporting CalDAV/CardDAV on their servers but not on their operating system? Or am I being downvoted for being critical of Google?
- Zikes 13y ago
  I think it's a pretty fair criticism.
- callahad 13y ago
  Your comment is of topical interest, but it doesn't seem to be terribly relevant to the announcement at hand. I suspect that's where the downvotes came from, though I've not personally voted either way.
- vetinari 13y ago
  What is the use case? For service provided by Google, use the supplied sync adapter. Yes, it is not CalDAV/CardDAV, but a whole google account package. For third-party services, use adapters supplied by these third parties. The third party adapters have the ability to be first class citizens in Android, but to make them so is up to their authors.
  - prg318 13y ago
    The use case is exactly what you have described: third party services. If one wants to run a Calendar service, open standards allow them to use a published standard protocol (CalDAV in this case) that clients can use regardless of platform. Most desktop calendar software (and even iOS AFAIK) support CalDAV and it seems that Google has cleverly omitted CalDAV support from their mobile OS, locking Android users into using Google Calendar with no other option. That being said, there's nothing stopping someone from writing a proper CalDAV/CardDAV adapter and releasing it on the Play Store. But with all of the claims of Google supporting open standards I was highly surprised to see that Google neglected to implement CalDAV/CarDAV in Android.

shmerl 13y ago

Good decision. Can Google also revert their decision to drop XMPP federation with their Hangouts now?

MikeKusold 13y ago
This has been beaten to death already. Hangouts supports way more functionality than XMPP calls for. In order to create a cohesive product, you can't have half your features not work with 3rd party clients that people might use. I think a better plea would be for Google to release Hangouts as a protocol.
- shmerl 13y ago
  > Hangouts supports way more functionality than XMPP calls for. While federating with XMPP they can expose only a subset. > I think a better plea would be for Google to release Hangouts as a protocol. I'm only for it. Which doesn't preclude the option above. Additionally, Google can extend XMPP if it lacks what they need.
  - Zikes 13y ago
    I would love to see classic Google Talk return, with status settings/messages, the ability to see if contacts are online, etc., however I'm not so sure extending XMPP is the way to go. It's my understanding that XMPP is an exceptionally verbose protocol, built on XML. It's great for interoperability, but there are better formats available now, including JSON and msgpack, which would be much more ideal for mobile IM.
    - shmerl 13y ago
      XML can be compressed: http://xmpp.org/extensions/xep-0138.html http://xmpp.org/extensions/xep-0138.html JSON isn't less verbose by the way. It also lacks namespaces, so I doubt it can help for a complex and extensible protocol.
    - stuaxo 13y ago
      True, there are loads of libraries to support XMPP on various platforms though.

mwcampbell 13y ago

I'm glad Google made CardDAV available and decided not to restrict CalDAV, at least for now. However, I wonder how long it will continue to support these standards, especially for users of the free services. Supporting these standards might not be directly in Google's best interest, since the more thoroughly Google supports task-specific protocols such as CardDAV, CalDAV, and XMPP, the fewer opportunities it has to present ads. So it may still be good for users to think about moving to services where the user is actually the customer.

jmillikin 13y ago
In all cases the user is the customer. Some customers pay with real currency (e.g. those who have enterprise accounts), others pay by loaning a few thousand pixel-seconds to advertisers. It's very much in Google's interest to encourage task-specific protocols, because they can be attached to subscriptions, and subscriptions are denominated in real currency. If Jane Smith knows that GAE has good support for syncing her calendar to her iPhone, she's more likely to use it as her company's email/calendar/documents provider.
jkn 13y ago
Could you be more specific? AFAIK there are no ads in Google Talk/Hangouts, Calendar and Contacts. Google is known for making the vast majority of its money from ads, but definitely not for putting ads in all of their products. Even if they did show add in these products, how does that relate to supporting standards as alternative means of accessing your data? Like in Gmail, which shows ads in the web interface but also supports POP and IMAP.

NameNickHN 13y ago

This is good news, I guess, but I'll play the pessimist and ask: "How long will this commitment hold?

zmmmmm 13y ago

While this is great and I sincerely congratulate Google for it, I still find the wording slightly disturbing. They say they were going to close down the API because only "a few large developers" were using it. Then that since they've heard from developers about a lot of "use cases" they've decided to change their mind. For me, openness is a relatively unconditional principle. You do it because it is a virtue in and of itself. To hear that we need to spell out specific use cases to justify something being open seems to indicate that Google slightly misses the point. Google shouldn't have to like our reasons for wanting things open. Google should have to justify why they are closed. Indeed, it's in the most unfriendly situations when the openness matters (ie: we want to get our data out of Google and move away from Google services). So while I'm happy to hear this, and I know I'm picking nits here, it still doesn't quite feel like the "old" Google that really made a principle out of these things.

dragonwriter 13y ago
> While this is great and I sincerely congratulate Google for it, I still find the wording slightly disturbing. They say they were going to close down the API because only "a few large developers" were using it. Incorrect. They said they were going to make it a whitelisted, by-request, partner-only API for that reason, rather than that they were going to close it down. There is a fairly significant difference. > For me, openness is a relatively unconditional principle. You do it because it is a virtue in and of itself. In the real world, few things are unconditional, and while Google has certainly claimed openness as one of its values, Google has never claimed that using open standards is an unconditional principal that is never weighed against other concerns.
skeletonjelly 13y ago
I'm thinking they've learnt from mistakes in their past where they've put in a concerted amount of effort to open source something only then to find out nobody wants to use it. Open sourcing it to their current standard requires code cleanup, documentation etc.
jessedhillon 13y ago
Google should have to justify why they are closed. This seems like a rather entitled position to take. By what reasoning is Google, a private, for-profit entity, obligated to make anything of this sort available to you?