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:


  • 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

  • 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)


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.


A wandering geek. Toys, shiny things, pursuits and distractions.

View all posts by

4 thoughts on “Shared Calendars, phase 2

  1. i think we can cheat the display problem just by putting a first initial on the events (like “c – dance class”), but it depends on whether people are mainly using their own clients or the web interface for viewing (i’ll probably mostly use my own client..)

  2. I wish I had faith that iCalendar (that’s the spec. iCal is the Apple application.) apps will get more robust. The spec is 6 years old. Noone seems to care enough to make robust ‘Corporate Calendaring’ based on iCalendar…hell, the spec authors are from Microsoft (who kinda have a small investment in Exchange) and Lotus (who have Notes…), so they’re out…
    The need has been there since years before the spec and noone took the ball and ran with it. Before DAV, I would have expected server-based apps with customized network clients or web interfaces…but noone did it, and noone’s done it yet.
    Apple’s come the closest – and yes, they use DAV, though I have no idea if it’s ‘extended’ in any way, and still, that’s entirely personal.
    Yes, I do care about this. No, I’m not trying to tell you your solution is bad – I’m really glad it works for you, it just emphasizes for me, over and over again, that there’s no open, standards based, robust solution trivally available, and no ‘open’ solution that’s either A) an incompatible lone project or B) is standards based and yet doesn’t have to be cobbled together.

  3. Oddly enough I’ve just put together almost an identical solution for the company I work for. The only diferences being we’re using Windows 2000 (Yuck) for our DAV server, and we have no out & out Unix platforms to worry about (OS X excluded). Just a few comments:
    1- Apples iCal works fine with web DAV. No special configuration is needed though it still wont “share” an editable calendar.
    2- Getting a Windows admin to enable DAV permissions is a pain. Circumvent them if possible.
    Mozillas calendar solution is nice but it crshes on Windows in almost every build. No explaination. I settled on WinDates as well.
    With regard to there being no “open standard” solution out there, I dont want to start the OS wars or anything, but look at the problem. Apple is almost 100% standards based now which is why they chose the ical format & on the mac system it works FLAWLESSLY. I’ve never heard a complaint about it other than the lack of actual sharing. mocrosoft on the other hand built their entire company around being proprietary and tryign to force everyone into adopting their formats, if they’re even so generous as to make the format available. They dont want competitive software or platforms so they want you to use, microsoft softeware on a Microsoft OS. Thats why standards will never be really useful. Windows media is a great example. Win media is Microsoft based, whereas iTunes is standards based. Exchange is another example.
    Honestly I believe if enough people put $ toward supporting the smaller standards based pieces of software, those applications WOULD get better. The only reason Microsoft got past windows 3.1 was because people paid them enough $ to pay developers. If its not standards based, I avoid it if there s ANY way to do so.

  4. There is a typo in the article, actually in the HTML, between “things like a” and “WebDav”. There is a missing quote at least in the Samba link. Can’t tell what the WebDav link is supposed to be.

Comments are closed.