Forum OpenACS Development: iCalendar and OpenACS Calendar

Collapse
1: iCalendar and OpenACS Calendar
Posted by Tom Jackson on 12/21/02 08:22 PM

The OpenACS Calendar package is quite the mess. Even with the recent overhall performed by Ben at OpenForce the package is not as useful as a general tool as it should be.

One problem I ran into that makes the Calendar a pain to use with DotLRN is that a calendar is expected for each package instance: you can't have a single personal calendar for one site. I thought this was an easy bug to fix since personal calendars are created on the index page of the package, but the package_id is required for almost every query in the package, and if you don't provide one, the library functions kindly provide it for you!

I personally didn't see the point in editing all those files so we could use a configuration option to change the behavior, because the major users of this package believe, and I agree that the package as a whole needs a rewrite.

Although I don't use calendaring, people who do seem to like one calendar. They want to be able to sync multiple calendars in case one calendar isn't possible, thus the need to follow a standard.

My question is: is iCalendar such a standard, where is a spec that is easy to understand, and should OpenACS shoot for providing a calendar that fully supports the standard?

Collapse
2: Re: iCalendar and OpenACS Calendar (response to 1)
Posted by Don Baccus on 12/21/02 09:11 PM
I think the reason for editing the files to use a parameter was to preserve the existing behavior if anyone wants it, but I wasn't really involved ...

iCalendar is a standard that defines an external representation for calendar data that is used by many calendar programs to exchange such data.  In fact our calendar package uses that format to export data to MS Outlook.  Gnome and KDE calendaring software also use iCalendar as does Lotus.

Another issue with the calendar package is that the object derivation is defined in such a way that attaching arbitrary objects to a calendar is a PITA.  You have to kludge things heavily.  It's been a long time since I've looked at this but there's an old thread around here somewhere in which I defined how I'd like to see it work and Ben had agreed at that time.  But there was never time for OF to reimplement calendar that completely, unfortunately.

Collapse
3: Re: iCalendar and OpenACS Calendar (response to 1)
Posted by Lars Pind on 12/22/02 08:23 PM
Another issue is that many large organizations already have a separate iCalendar-compliant calendaring server, and what you really want is for OpenACS to use that server as its data store, instead of storing it in the OpenACS data model. That way you can view and manage your calendar through OpenACS, through Outlook, as well as through any other piece of software on your intranet who knows how to speak with the iCal server.

Wasn't this what Talli's Momentum project was about?

See also this U Washington project.

Collapse
4: Re: iCalendar and OpenACS Calendar (response to 1)
Posted by Tom Jackson on 12/22/02 09:29 PM

Thanks for the great reference. The ucal requirements doc is very helpful in thinking about the subject. I'm looking to see if they are publishing a datamodel for the message storage, etc. But the requirements look easy for OpenACS, although there are a lot of them.

I like your idea of providing an interface to the message store, I think ucal has the idea of an aggregator, which combines calendars from multiple sources.

Ucal also has an interesting idea of attaching calendars to 'resources'. In OpenACS terminology, this could just be any 'object'. Then you can view the object's schedule, and schedule the object. That might lead to a neat general scheduling package: schedule a person, room, workstation...

Collapse
5: Re: iCalendar and OpenACS Calendar (response to 1)
Posted by Don Baccus on 12/23/02 06:00 AM
The first concept (interface) cries out for a service contract  model to attach a UI package to calendar storage packages, one of which we might provide in the OpenACS toolkit but which might be provided by standard calendaring software instead.  Fulfill the service contract, and the user doesn't care who is doing it.

The second notion is pretty much what Ben and I had talked about several months ago - you should be able to attach calendars to objects and arbitrary objects to calendars.

Collapse
6: Re: iCalendar and OpenACS Calendar (response to 1)
Posted by Tom Jackson on 12/23/02 06:54 PM

After reading a little more about iCalendar, I stumbled across a nice summary of the different pieces needed for an implimentation. The summary RFC 3283 contextualizes the various pieces like this:

The relationship between calendaring protocols is similar to that between e-mail protocols. In those terms, iCalendar is analogous to RFC 2822 [Internet Message Format], iTIP and iMIP are analogous to the Simple Mail Transfer Protocol (SMTP), and CAP is analogous to the Post Office Protocol (POP) or Internet Message Access Protocol (IMAP).

[CAP] seems to specify the granularity of access control needed to support iCalendar functions, so maybe that is where to look for ideas on the permissions required.

Things not addressed by the RFCs are user administration and user notification, but OpenACS already has this partially covered.

It is too bad that a new important service like calendaring has been shoehorned into the old and rusty email infrastructure. Apparently an important consideration is to provide a message format that is cut-and-paste'able on the deficient windows platform. OTOH, everyone knows the limitations of email and email software. Having some kind of MIME module for AOLserver would help out quite a lot.