Quoting Trent W. Buck (trentbuck@gmail.com):
From what you say, it sounds like the phones don't actually run caldav clients, they instead just run an http/html client that speaks to some web app at google.com/apple.com, and the web app once used caldav internally?
Sadly, I'm no expert at this. (I don't even so far use smartphones.) I suspect that it all depends on what sort of client service on the phone you're talking about, i.e., is it one of the ones designed to work with real iCalendar scheduling servers (w/access protocols), or is it just a Web wrapper devoted entirely to a Web site fronting scheduling data.
Hrm, that might explain why every time I look at "add calendars" to my existing postfix+dovecot stack, there seems to be some missing magic in between "caldav server is installed" and "people with phones can do useful things with it".
I do know that, if you engage with the communities using software like Radicale as server-side solutions, they can tell you a lot about what works client-side and anything required to mesh the two -- perhaps the missing glue in your (one hopes, roughtly corresponding) server stack that's purported to make people with phones do useful things to your server if you do the 'add calendars' step. To know more, I'd have to do the same from-near-zero research you would, and you have the advantage of a test platform. ;-> And, of course, the typical 'person with phone' wouldn't know jack, about what software he/she must have installed to implement commodity network protocols and to interpret received data. So, no point in asking them. They'd have no clue, in the main. But, to help get around that: Taking a quick gander at Radicale (assuming it's feature-comparable): Front page encouragingly says 'Works with many CalDAV and CardDAV clients.' Well, peachy. https://radicale.org/clients/ elaborates: Radicale has been tested with: Android with DAVdroid GNOME Calendar, Contacts and Evolution Mozilla Thunderbird with CardBook and Lightning InfCloud, CalDavZAP and CardDavMATE Goes on to give specific tips. Of course, this information would be useful to _you_ only to the extent that your server stack truly has the identical capabilities, and I haven't a clue what a postfix+dovecot stack with 'calendars' would comprise/do, really. I was curious about 'DAVdroid'. Looks like its successor codebase is something called DAVx, described as 'a CalDAV/CardDAV management and sync app for Android'. So, there ya go. But if the user wants a contacts, calendar, or tasks app (to edit/view contacts, events, tasks etc. on a smartphone), that's a separate need. DAVx just manages the CalDAV/CardDAV data flow between remote content providers and the Android API. For example, Samsung's Android devices reportely include in the OS build something called Samsung S Planner (more recent name 'Samsung Calendar'). I followed the non-progress of scheduling software on Linux for long years starting in 1999, when the CTO, David Sifry, of my company Linuxcare (a now long-dead dot-com) was known for, among other things, an alphaware set of scheduling software called OpenFlock[1] implementing some of the IETF alphabet-soup-du-jour protocols for the purpose that never went anywhere. (I remember these included BEEP and iTIP.) The project soon got unceremoniously abandoned, far from finished. One of the lessons of study that and similar debacles was that the chaotic churn of protocols and every little device (which then included idiosyncratic PDAs) or client software having its own quirks and needs was a killer. And, the thing is, I think many such projects gave up in part because of standards churn and 'Oh, I see you just added LDAP authentication but it doesn't work with _my_ LDAP'. And also that there wasn't agreement about what client-side needed to do, hence no agreement on linking protocols. What was required was a few strongly present-in-the-market clients all implementing the same core protocols and having the same expectations of a server. Then, coders would have a stable target to shoot for. I'm guessing we're appoaching that sort of pragmatic consensus that delivers a commodity standard. I would further guess that https://radicale.org/clients/ might be deemed a place that goes into the details of that commodity standard. Hope that helps. [1] https://www.usenix.org/legacy/publications/library/proceedings/als00/2000pap...