6

I need to implement a Google-Calendar-like scheduling web app. One of the requirements is synchronization with other scheduling applications, like Google Calendar, Microsoft Exchange, Office 365 and IBM Lotus.

I came to the conclusion that there are basically two ways of doing this:

  1. Implementing a full CalDav-server (RFC4791)
  2. Adding a mailserver to my application, thus enabling it to send and receive emails with iCal attachments. By every modification of an event, the server would send another email to all the participants.

There are many questions that cross my mind and I would really appreciate a commentary from anybody who's got experience with working with CalDav or developing calendaring applications.

  1. Is the second way (sending iCal files around) a relatively good replacement for a full CalDav-server?
  2. What are the pros and cons of the first and second approach?
  3. What is generally a preferred way to synchronize various scheduling clients?
  4. Which one requires more effort?

Thank you in advance.

Improve this question
2
  • What's your progress in creation of calendar As I see this post is already 5 years old. Did you finished your calendar ? What problems have you faced after choosing the second way (ical) ? I'm now facing the same issue Commented Jul 21, 2023 at 12:55
  • I think sending iCals around is a better approach. In the end, the project was scrapped, so we didn't get to finish. Thus, I can't really address your question about the problems encountered on the way. Commented Jul 23, 2023 at 8:00

1 Answer 1

Reset to default
4
+250

This is tricky, but...

In short order CalDav is not a well supported standard. Everybody adds on their own little bits here and there and can really make it a nightmare to use as an integration point.

iCal is better supported in most products but not all. On the plus side you can usually have an entire calendar in an iCal file and just server it without having to mail it around.

  1. There not the same thing, hosting a generated iCal file may be a good replacement for the parts of CalDav your trying to use. But hosted iCal files will likely be read only. (but so would mailed files)

  2. See above. CalDav is great if you can control all ends but horrible if you have to support an unknown or growing list of applications. iCal files for each appointment would be a lot of emails. Especially if you use propose and change scheduling (where one person picks a time everyone looks free and then everyone is allowed to reject and reschedule till a good time slot is found). Hosting an iCal per calendar may be better but would be read only. Though most any application can support it.

  3. A phone call. Seriously. No one out there has gotten this correct, ever! What's worse is that every one uses calendars differently, even in the same organization. Your trying to impose order where no order has existed before. Many people have tried and failed, specially when allowing many clients. Your best bet is to just tell the user what is on a calendar and let them figure out how to add it to their PIM.

  4. Both are gonna be pretty bad. CalDav is a larger starting effort, but both are going to have huge support costs. I would be you would need a dedicated call center person before you hit 100 end users.

Calendars are funny things, different people use them differently.

For example, I have a meeting tomorrow at 11:30. I slotted the meeting from 11:30 to 2:30 and then two "meetings" from 11:00 - 11:30 and 2:30 to 3:00 for travel time. In addition I have a meeting Thursday at 11:00 which I have no travel time for, and one at 2:00 which I have no travel time for. Friday at 5pm I have a 6 hour "meeting" blocked out to make sure I get to do some family stuff.

This works for me. It helps my clients see Free/Busy info in a way that is meaningful to them, it helps my wife see when to schedule things like Dr. Appointments for the kids, and it helps me plan my work around what I need to do. However, for the next guy this may be a horrible system.

In addition there's reminders, alerts, free/busy indications, attachments, geo-location, and room bookings that all have to be accounted for, and are all accounted for differently in different systems, and even in the same system.

What your attempting to do (sync many different system's calendars) is one of those tasks that may never be doable because of the human element. But if you can hone in on what your end users want, and make it possible to deliver that while staying generally out of the way of how they want to use their tools, you could have a very good product.

Improve this answer
3
  • Thanks a lot for the input. I forgot to mention that the data model is already implemented and can handle the intricate combinations of recurring event definitions. So I wouldn't be storing iCal files, but rather transform them into proper relational entities that can be saved in a database. Commented Apr 10, 2018 at 7:10
  • The back end won't matter is the transport and front end that make it so difficult. Commented Apr 11, 2018 at 15:49
  • For the record, for the time being, we chose the second option (not going with CalDav). Commented Apr 21, 2018 at 9:40

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.