Shared Calendars, phase 2

For folks following at home, Catya, Ted and I decided to try and sync up all our calendars so we could share them in one place, and view each others schedules. As I’d like to be able to do this for my business, this seemed like a good place to ‘test the waters’ as it were.

There were several problems facing this entire project:

• The calendars needed to be accessible to all of the users, at any time.
• We had The Big Three for client platforms (Windows, Mac, and Unix), so whatever solution we came up with had to play nice with all of them.
• Decent integration with existing calendaring tools. There are ‘online’ web calendar systems, but I have yet to see one that works really well, and there are SO many good client apps.
• A web-based browser should be around to at least view the calendars remotely,if not edit them in place.

The Format – We All Need to Speak the Same Language

The logical solution seemed to be something involving iCal an Internet Calendaring standard that was put together in 1998, but didn’t really get into common usage until a year or two ago. The specification defines only the structure of a calendar description file, not how to share them or update them.

The Protocol – How Do We Get It From Here To There?

The next step was to come up with a way of posting and viewing the calendars in a shared environment. The short story of how iCal works is calendar data is stored into a single iCal file (usually something with an ‘ics’ extension). Those calendar files can be copied around and moved, and can be viewed in with several other calendar files simultaneously. So if each user in a workgroup generates their own .ics file and puts them in a commonly accessible location, a smart client application should be able to view all the files in one view.

We wanted our shared data store to be available not only on the local LAN, but also remotely from laptops / work machines, so things like a Samba share weren’t going to work. I had heard about using WebDAV for file and content publishing to webservers, and decided to give that a whirl. It also appeared that many of the iCal driven applications were using WebDAV for publishing. Sounds good

I took one of our Apache webservers and decided to enable WebDAV on it. This turned out to be simply a matter of building the mod_dav module, installing into into my apache hierarchy, and adding the module lines to the httpd.conf. A quick restart, and voila! We had a webdav enabled server

Next step was to enable permissions and passwords on the DAV share. SInce this entire thing runs inside Apache, it was a matter of simply putting a .htaccess file within the DAV directory (as defined in the httpd.conf), and setting up the normal HTTP Authentication settings. This is easy to test with or without webdav clients, just hit the URL where the DAV share is via a browser, and test the login.

The Clients – How to Edit Stuff

So far so good. Next we need the client apps. Personally, I use Evolution 1.4 from Ximian for just about everything. THe calendaring, mail, and task list tracking stuff in it is wonderful. My only whine at the moment is it has no automatic publishing of Calendar (.ics) files to a DAV server, however it uses iCal files natively for all calendar operations, so the only magic needed is to get the native .ics file into the DAV environment. I’m hacking this right now with a single shell command:

scp ~/evolution/ocal/Calendar/calendar.ics [myhost]:[path to dav dir]/dbs.ics

I’ve set up SSH keys so this doens’t require a password, so I simply need to invoke that whenever I want to publish my current calendar to the DAV share. Works like a champ.

For Windows, Cat played around with Mozilla’s Calendar tool which has the ability to edit any .ics file within the DAV environment. Although that’s a bonus, she found the interface difficult to deal with. Instead, she went with WinDates. This is a sexy package with some nice tools, and allows publication to a DAV environment, with built in HTTP authentication and everything. The only thing it doesn’t do is allow her to edit someone elses calendar file remotely (via the DAV share), though she can subscribe to the calendar remotely, so any time I make an update to my calendar and publish it, she’ll see it.

Because the .ics files are now in a DAV environment within an Apache server, it was simple to install a tool to browse those .ics files in place. We ended up with phpiCalendar, a VERY slick browsing tool that offers multiple views, merged calendar views, and a very well put together interface. The two things it doesn’t do are allow editing online (understandablly this is a complicated thing to do), and coloring of individual calendars. We’d like to be able to say “Cat’s calendar entries are green, Daves are blue, and Teds are orange”, but browsing through the stylesheets and forums, looks like it’s not possible.

We haven’t worked with the Mac side of things yet, though Apple calls their calendar solution for OSX ‘iCal’, and apparently supports published shares, so we’ll see how this one pans out.

The Solution – So How’s it Working?

We’ve been running with this configuration for about a week now, and things are working great. Changes to my calendar are published into the DAV environment, and Cat and others see the changes reflected immediately. She can make changes to her calendar, and WinDate publishes it right into place.

This solution seems to be working for us now, though there are limitations. Here’s Pros and Cons breakdown:

Pros
• Multi-client access to a shared environment
• Web-browseable from any location
• Standardized format that any of the clients can edit
• Server tools are standard, easily integrated into existing environment
• Client tools are well established and integrated into desktops

Cons
• Web browser tool doesn’t differentiate ownership of calendars, though it can filter views to a specific user.
• Still no group scheduling other than viewing all merged calendars. This will probably be a function of smarter iCal clients, but to schedule something for everyone, you still have to manually coordinate it.
• Evolutions iCal support is weak. The only advantage it really has is it uses iCal natively, and therefore can just be ‘copied’ up. No publishing or subscribing services in it (I’ve heard that Evolution 2.0 is going to fix this)

Conclusions

iCal coupled with WebDAV makes a powerful and flexible environment. I believe that the solution we’ve come up with will work for 90% of the work we need to do. As the iCal clients mature,and we find better ways to work with things, we’ll be able to go that extra 10% to get group scheduleing and other functions working.