Hacker News Reader

Comment by prg318 | Hacker News Reader

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

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

View on HN

It's one thing to allow people access to their Calendar and contact information in Google's systems via an open protocol.

It's another to provide an implementation of that protocol on a different system. Why should they? They use their own protocol for this task. They don't provide an XMPP client either. Let others fill that gap, though I understand your frustration that current candidates are insufficient.

The developer says it will be "open sourced" once it reaches 1.0

The following is from the FAQ[0]

    Why don't you make it open source right now?

    Because it's not ready yet. Some parts of the source code are quite messy, it would be too embarrassing to publish it ;-)

Silly.

[0]: dmfs.org/wiki/index.php?title=CalDAV-Sync_FAQ

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?

I think it's a pretty fair criticism.

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.

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.

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.

Seems like a crazy high bar to hold for "supporting open standards". Google made the APIs available and allow you to provide your own client on their platform with minimal to no interference. They just don't do one auxiliary part that would amount to not much more than making competing with Google Calendar slightly easier. Competition doesn't mesh with the kumbaya, sunshine and happiness tone of open source, but it is fairly strident stance to say companies have to go out of their way to hurt their own products to be open.

I do not think that supporting a standard protocol for calendars and contacts that all other OSes use is a "crazy high bar". I would expect that a mobile operating system whose primary purpose is greatly dependent on contacts and calendar to support the same standard that other OSes use.

In that case, I guess that we can praise Apple for meeting the "crazy high bar" for "supporting open standards" since Apple decided to include support for the most widely used open protocol for calendar and contacts in their mobile OS.

I don't keep up much with the Microsoft space, but aren't they supporting Cal/CardDAV now too on their windows 8 phones?

If so it is a bit of a weird thing for Android not supporting those protocols to be considered a 'crazy high bar' of effort. If the other smartphone OS's support them, it is somewhat curious that Google doesn't as well. Even when they support it server side. Strikes me a bit too much like a Hotel California situation.

Microsoft has CalDav/CardDav support coming for WP8 in the next update [1]. iOS has had CalDAV/CardDAV support to boot (AFAIK).

I'm not sure why posters ITT are acting as if I am making demands to Google. In my original post I simply stated that "it would be nice" to see native CalDAV/CardDAV support in Android. But apparently making suggestions for a better product by providing the same support for open standards that other OSes provide is "a childish perspective" according to a Google employee [2]. I guess we need to keep in mind that a client and a server are barely even related [2]. TIL.

[1] http://www.engadget.com/2013/05/14/windows-phone-8-summer-up...

[2] https://news.ycombinator.com/item?id=5827461

Neither Apple nor Microsoft allow you to plug-in your own sync adapter. What if you do not want to use CalDAV/CardDAV, but your own protocol?

For example, Samsung, Asus and Sony do exactly that. They provide their own sync adapters. Maybe that's more important to them (and their customers) than generic CalDAV/CardDAV.

Cool didn't know it was next update for windows 8, but still a good sign.

I do find the dichotomy of supporting "open" protocols to their service, but not from their operating system a bit odd. Though in that respect Apple isn't much different regarding imessage/facetime/etc...

I guess I would rather have my device/os support open standards over the service I might use them upon.

That's because one is a service, and one is an open operating system. If a service doesn't support a protocol, you can't use that protocol with it, so there is demand that the service support the open protocols that most clients have implemented. If an open OS doesn't have built-in support for a protocol, you can choose to add it. It's apples and oranges. It's like saying your laptop doesn't support a particular printer because you have to install a driver to print.

For an OS, it makes more sense to err on the side of supporting fewer protocols by default and allowing users to clients to add the ones they need than bloating it up with all possible protocols you ever might want to connect to on any server, anywhere.

I think the key point is that while the Contacts and Calendar applications are typically pre-installed on an Android device, they are still applications and not a part of the operating system itself. Any third-party developer could create a competing application that would have equal status on a device, while supporting CalDAV and CardDAV as well.

Trying to build CalDAV and WebDAV into the Android OS wouldn't work, because they would be dependent upon those applications, which would then make them essential OS applications.

Contacs ("People") and Calendar are part of AOSP, althrough most vendors do not ship them.

It does not matter, as neither AOSP nor vendor-specific Contacts or Calendar applications contain any protocol code. These frontends use contact and calendar specific content providers, which in turn provide plugin based API for sync adapters. Google's own sync adapter is such plugin, as well as Facebook's or even Microsoft's (for Skype contacts).

It is true, that there are no CalDAV/CardDAV sync adapters on the devices. However, because not everyone is interested in one, it is perfectly fine to install them from Play Store for those interested.

Perhaps you could refer to a "standard" CalDav client interface included with Windows? Or .Net? I can't think of any OS that provides a standard library for this... Maybe Linux has a few, but not sure that it's in the box... same for OSX.

OSX: iCal Linux: Evolution/Sunbird/Lightning (Thunderbird plugin) I'm not sure if Outlook is still shipped with Windows but IIRC I remember Outlook supporting CalDav in the past.

I do realize that all of these run in userspace and technically are not a part of the Operating System but they are provided with the distribution/purchase.

Those are CalDav clients... they aren't using a library exposed by the OS for custom apps... they each have their own CalDav client library.

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.

I'm not acting as if it is Google's responsibility to support any protocols at all. It's just curious that Google would implement a protocol on their servers but not on their operating system. Am I demanding anything? No. I am blaming anyone? Not at all.

The personal attacks based on your perception of my comment are frankly unprofessional and completely unnecessary.

I didn't make any personal attack against you. I answered your question about why you were getting downvoted by describing what your comment sounded like to me. If you didn't want to know what people thought about what you said, you shouldn't have asked.

Not the OP; but you do say "It's just . . . a childish perspective" - slightly hard to not construe that as a personal attack.

But I suppose you have a different standard for that sort of thing.

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.

user: jamesaguilar about: Staff software engineer at Google.

Apparently not.

Reply on news.ycombinator.com