2

Would a CalDAV server provide faster syncing than .ics files? Specifically for iOS and Google Calendar. I realize the client is responsible for updating and frequency.

Many posts indicate Google Calendar is slow to update .ics feeds. I tested and after 6+hrs, it still hadn't updated the changes I made to the .ics file.

Same issue with iOS. Initial load of the .ics file loads the calendar fine. But after changes to the .ics file, iOS never makes another request for the file again for days (watching apache log file).

I'm trying to share a calendar feed. I only need to post the calendar (read-only). I don't need the user to make changes. .ics seems easier than running a full CalDAV server. If I do, is it worth it? Will it sync to Google Calendar, iOS, and other clients quickly (minutes, not days)?

Markus Unterwaditzer
  • 7,992
  • 32
  • 60
user3185615
  • 41
  • 1
  • 5
  • Running your own CalDAV server does not imply that you can sync with google calendar. It's more likely that you cannot. – Evert Feb 17 '15 at 14:42

3 Answers3

3

CalDAV is a better choice if your data changes quite a bit anyways. It'll only send changed data (instead of the full calendar), which is particularly important on mobile devices. (you don't want to sent a full 1MB calendar to the client just because a title of a single event changed ...)

For webcal, checkout this one: Set Update Limits on iCalendar Feed. You might want to try the REFRESH-INTERVAL and X-PUBLISHED-TTL properties on your calendar. I suppose if you don't have such, clients will fall back to the weekly refresh ...

Having said that, CalDAV updates should definitely default to faster refreshes (like 15 mins instead of a week?).

For essentially instant refreshes on iOS/OSX, use either iCloud or OS X server to host your calendar. Changes to such will be pushed to the devices via APS.

Maybe it's also worth noting that you can host subscribed/webcal calendars within a CalDAV account. And configure the refresh settings of such via WebDAV properties.

The right approach depends a little bit on what you actually try to achieve ;-)

P.S.: All this doesn't help you with Google calendar clients as they don't support CalDAV in the first place ...

Community
  • 1
  • 1
hnh
  • 13,957
  • 6
  • 30
  • 40
0

Normally, a .ics file is for importing static data into a calendar. I wouldn't expect to use a .ics file if the entries are going to be updated and need to be pushed to the client. Think of it like a snapshot.

CalDAV is a lot more sensible here: it's a whole protocol for sending and receiving updates.

chiastic-security
  • 20,430
  • 4
  • 39
  • 67
  • 2
    Sending .ics via HTTP GET (aka 'subscribed calendars' / webcal) is a very common / widely used mechanism to publish public calendar data. OS X supports refresh settings from 5 minutes to once per week. A major advantage is that this is widely supported, including Outlook and such. The big disadvantage is that a refresh is always a full calendar refresh instead of a partial update - in other words it is very inefficient for data which changes a lot. – hnh Aug 19 '14 at 20:16
  • (I know this is an old question...) You can reduce the size of a ics file by removing events that are more than x days in the past or not in the near future, depending on your needs. (I've read somewhere that some clients look at the size and adjust the update interval based on that, but no official info) – WiRa Oct 30 '19 at 12:37
0

As of today, CalDAV is not an option in your scenario I'm afraid:

  1. There is no such thing as a caldav url.
  2. Clients could, through a few queries, make the distinction between a basic ics file and a CalDAV collection but they currently don't. So you will have to expose that ics versus caldav business to the end user somehow.
  3. Some of the CalDAV clients that you seem to care about (iOS) don't offer a way to anonymously "subscribe" to an individual CalDAV collection. They will interact only with a full-fledged CalDAV account.
Arnaud Quillaud
  • 4,420
  • 1
  • 12
  • 8