3 ms·

Question: how hard would it be to write a Google Calendar API proxy that serves CalDAV requests? I'm reading the spec and it seems to be only about 100 pages lo

Question: how hard would it be to write a Google Calendar API proxy that serves CalDAV requests? I'm reading the spec and it seems to be only about 100 pages long. I guess the question is whether there is any economic incentive to do so.

josteink 14y ago
A rule of thumb is that anything which involves calendar-sync, no matter how trivial it at first seems, will get hairy, ugly and have potential for amazing bugs you could never even imagine, the second you stop thinking about it and start writing code. The amount of edge-cases is usually beyond belief.
- joedevon 14y ago
  WORD!
  - Dru89 14y ago
    As in, all of your calendars should be managed by Microsoft Word?
    - joedevon 14y ago
      No
- Osiris 14y ago
  My day job is writing a calendar product. I'm currently re-writing the entire product as an API. Something as simple as "Create a new event" has taken months of work (when you save an event you have to update recurrences, alarms, attendees, etc.) Our legacy code has an event save method that's a few thousand lines long. It's the one part of the code that we avoid at all costs because a seemingly minor change can break some weird edge case. We also have a CalDav module that works but also has weird edge cases when different calendars handle things in different ways. For example, you have an event that starts on a Monday, set to repeat on Wed and Fri for 10 occurrences. Do you display the Monday occurrence of the original event even though it's not in the recurrence rule? If so, does it count as one of the 10 occurrences or not? In our testing, iCal, Google Calendar, and Outlook all handle this same case in completely different ways.
  - tracker1 14y ago
    I don't blame you.. I had to work on an access request system, and the SLA/Scheduling bits were nightmarish with huge swaths of hard to follow code... I finally got so frustrated I spent a 15 hour straight period pretty much ripping out the majority of said logic and had it all in UTC from front to back, and had any "local" conversions client-side... there was still a bunch of code in place to handle weekends, and holidays (which don't count against SLA), but this really wasn't timezone dependant so much. Can't imagine what a pain a full on calendar project would be.. I looked at CalDAV at one point, because I wanted something that ran outside of Apple's OS early on, but pretty much dropped the idea less than a week into it.
- tracker1 14y ago
  Yeah.. timezones and date-time logic are no fun at all. And the less well the environment supports such things, the less fun it gets. I don't know why Google is shutting down the caldav support.. guessing that imap for gmail will be on the chopping block soon.
  - josteink 14y ago
    guessing that imap for gmail will be on the chopping block soon. If that were to happen, I'd be shocked. But as a precaution I should probably start doing an IMAP export/sync on a workstation on a regular basis. It'd be pointless to lose something as easy to backup as mail just because of you having too much faith in a service-provider.

josteink 14y ago

A rule of thumb is that anything which involves calendar-sync, no matter how trivial it at first seems, will get hairy, ugly and have potential for amazing bugs you could never even imagine, the second you stop thinking about it and start writing code. The amount of edge-cases is usually beyond belief.

joedevon 14y ago
WORD!
- Dru89 14y ago
  As in, all of your calendars should be managed by Microsoft Word?
  - joedevon 14y ago
    No
Osiris 14y ago
My day job is writing a calendar product. I'm currently re-writing the entire product as an API. Something as simple as "Create a new event" has taken months of work (when you save an event you have to update recurrences, alarms, attendees, etc.) Our legacy code has an event save method that's a few thousand lines long. It's the one part of the code that we avoid at all costs because a seemingly minor change can break some weird edge case. We also have a CalDav module that works but also has weird edge cases when different calendars handle things in different ways. For example, you have an event that starts on a Monday, set to repeat on Wed and Fri for 10 occurrences. Do you display the Monday occurrence of the original event even though it's not in the recurrence rule? If so, does it count as one of the 10 occurrences or not? In our testing, iCal, Google Calendar, and Outlook all handle this same case in completely different ways.
- tracker1 14y ago
  I don't blame you.. I had to work on an access request system, and the SLA/Scheduling bits were nightmarish with huge swaths of hard to follow code... I finally got so frustrated I spent a 15 hour straight period pretty much ripping out the majority of said logic and had it all in UTC from front to back, and had any "local" conversions client-side... there was still a bunch of code in place to handle weekends, and holidays (which don't count against SLA), but this really wasn't timezone dependant so much. Can't imagine what a pain a full on calendar project would be.. I looked at CalDAV at one point, because I wanted something that ran outside of Apple's OS early on, but pretty much dropped the idea less than a week into it.
tracker1 14y ago
Yeah.. timezones and date-time logic are no fun at all. And the less well the environment supports such things, the less fun it gets. I don't know why Google is shutting down the caldav support.. guessing that imap for gmail will be on the chopping block soon.
- josteink 14y ago
  guessing that imap for gmail will be on the chopping block soon. If that were to happen, I'd be shocked. But as a precaution I should probably start doing an IMAP export/sync on a workstation on a regular basis. It'd be pointless to lose something as easy to backup as mail just because of you having too much faith in a service-provider.