
Making Google’s CalDAV and CardDAV APIs available for everyone - Zikes
http://googledevelopers.blogspot.com/2013/06/making-googles-caldav-and-carddav-apis.html
======
zmmmmm
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
> 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.

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

~~~
Matt_Cutts
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-...](http://googledevelopers.blogspot.com/2013/06/making-googles-
caldav-and-carddav-apis.html) 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.

~~~
Serow225
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.

~~~
kllrnohj
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
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?

~~~
danudey
OS X's mail client supports IMAP push as well.

------
mwcampbell
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
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.

------
prg318
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.calda...](https://play.google.com/store/apps/details?id=org.dmfs.caldav.lib)

[2]
[https://play.google.com/store/apps/details?id=org.dmfs.cardd...](https://play.google.com/store/apps/details?id=org.dmfs.carddav.Sync)

~~~
prg318
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?

~~~
jamesaguilar
Because you're acting like it's Google's responsibility to provide a client in
addition to a server. This is not the case. In fact, the two are barely
related.

Or perhaps because it's kinda silly to say, "Oh, you gave me one thing? Now
give me another thing!" It's just . . . a childish perspective? I'm really not
sure how to describe this.

~~~
jhenkens
Is it not in Google's motivation to make Android the best phone platform it
can be? The lack of native CalDav sync irritates me (the app/plugin listed
works fairly poorly, from my experience), as well their horrid excuse of what
they call "Exchange" support on Android. If you aren't using GMail, they make
it very clear you are a second class citizen on Android. Part of the reason I
left it after using it for a month.

~~~
prg318
user: jamesaguilar about: Staff software engineer at Google.

Apparently not.

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

~~~
MikeKusold
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.

~~~
jmillikin

      > In order to create a cohesive product, you can't have
      > half your features not work with 3rd party clients that
      > people might use.
    

Why not? Having clients with a range of functionality is how the entire open-
standards world works. Somehow, the world wide web continues to work just fine
even though it's possible for people to use any browser they want.

If a user has a third-party client, and it doesn't support some fancy feature
that the first-party client supports, that doesn't seem to be a big problem. I
don't think a significant number of people would care if using video
conferences required the official client.

~~~
UVB-76
The web browser analogy is a poor one. There are countless standards in place
for the reproduction of content on the web, and these days most popular
browsers are quite good at supporting those standards.

When it comes to a commercial product like Google Hangouts, allowing users to
use unsupported third-party clients is a big risk. People will conflate the
client and the service; problems with the client will damage the reputation of
the service, and so on.

~~~
shmerl
E-mail analogy is better. Imagine a service, which only allows using one
e-mail client and doesn't allow sending e-mails to anyone outside itself. I
wouldn't want to use such service.

~~~
dragonwriter
Interestingly, such a system (e-mail like system which only supports first-
party clients and can only send to and receive from other users of the same
service) is a common feature of web discussion fora and social networking
sites.

 _You_ might not want it, but such services haven't exactly failed in the
market.

~~~
shmerl
Your example isn't good, since forum messaging has limited scope, while e-mail
is generic. Instant messaging can have limited scope in other scenarios (let's
say you chatting with some support representative for some service). It can be
generic as well. Here we are discussing generic instant messaging. Therefore
it's proper to compare it to generic e-mail. When it's artificially limited by
the service walls, it's unacceptable.

 _such services haven't exactly failed in the market._

Indeed, services like AIM, Skype, Whatsapp and etc. have many users, and are
presented as generic instant messaging services, yet they don't allow their
users to communicate with others. It's somewhat surprising to me, that people
are ready to accept that fact. For some reason they'd see cutting their e-mail
off from other servers as unacceptable, but the fact that they are confined
within the network of proprietary IM clients doesn't bother them, even though
because of that they need to use many clients or protocols to communicate with
different networks having an account on each.

~~~
dragonwriter
> Froum messaging has limited scope. E-mail is generic.

Making a system closed by boundaries automatically gives it limited scope, but
forum messaging isn't any more limited in scope than results from those closed
boundaries. Ditto with social network-based closed mail-like messaging.

~~~
shmerl
See above. Social network messaging is presented as generic. So I won't
compare it with forum messaging.

~~~
dragonwriter
At this point, I'm not even sure what your point is, since you said my
examples were bad, and now seem to be saying that your initial criticism
doesn't apply to one of my two examples, and that you wouldn't compare the two
examples I gave with each other.

~~~
shmerl
My point is, that there are scenarios when closed messaging networks are
acceptable, and there are scenarios when they aren't, but despite of that,
people tolerate them in case of IM, which allows various messaging services to
get away with it. I said that I really don't understand why that happens,
since in case of e-mail they don't tolerate it.

Hangouts, FB messaging and etc. are generic cases, not the ones which should
be acceptable as confined environments (like your example of the forum
messaging).

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

~~~
Shooti
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
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
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
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?

~~~
ChrisClark
Actually, application-specific passwords have nothing to do with Google
Authenticator. Authenticator is only for the two-factor code. Application-
specific passwords are just individual passwords you can set up for anything
that doesn't support the two-factor authenticator login.

Just so you don't have to share the same password with multiple products.

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

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

------
rasterizer
Not merely a reinstatement: OAuth 2.0 as well.

