Child pages
  • CalDAV Proposal
Skip to end of metadata
Go to start of metadata

Authors

Andrew Petro

Problem statement

An institution is adopting an enterprise personal calendaring solution for students and faculty. Sakai also includes a personal calendaring solution, representing the schedule associated with each course as well as a "My Workspace" synoptic aggregated calendar view across these courses.

Without further integration, this yields a disjointed user experience where some personal calendaring events important to the student are presented only in the Sakai calendaring tool, whereas other personal calendaring events important to the student are presented only in the enterprise calendar.

The problem is that there are different stores of calendar data and different views on that data, disjoint such that Sakai calendar data is not visible in other views.

Proposed solution summary statement

Unicon proposes to enhance the Sakai calendar service to implement an additional, CalDAV-backed calendar store as an alternative to the current Sakai-local storage of calendar events. Georgia Tech is sponsoring this project, with an eye toward deploying it against a Zimbra (ZCS 5) calendar store as a proof of concept and reference implementation.

It will not, however, be tied to particular Zimbra features, and the code which will be developed for the Sakai trunk will be agnostic as to the calendar store. A possible integration with other CalDAV-supporting implementations (e.g. Bedework) will help guide the effort.

Since these calendars would then be stored and managed in Zimbra, they would allow Zimbra to be the cohesive, single, central view of calendar information for students and instructors at Georgia Tech. The result will be a single comprehensive calendar user experience in Zimbra. In particular, since Zimbra will be storing the calendar information related to Sakai sites, Sakai calendar information becomes available among the calendaring information exposed to end users via the Zimbra Mobile user experience.

Assumptions and Caveats

What is not proposed in this initial increment of work

Not proposed: replace calendar tool in Sakai

This initial increment of work does not propose replacing the Sakai calendar and scheduling tool in Sakai. What is changing with this effort is an underlying capability for the Sakai calendar and scheduling tool to store its events into a CalDAV store, not a change to the end-user-facing features of the calendar tool.

Not proposed: ETL integration

This proposal does not contemplate extracting calendar information from Sakai, transforming it into Zimbra calendar events, and loading these events into Zimbra as Zimbra-locally-managed non-iCal-derived events, thereby creating an ongoing synchronization problem between the Zimbra representations of these events and the Sakai representations of these events.

Rather, this proposal contemplates enhancing the Sakai calendar service to remote its storage and access to calendar information over CalDAV.

The result of the proposed work will be analogous to the Cambridge content hosting service multiplexer approach allowing schools to use both the Sakai-local database-backed repository and the JCR repository for content hosting. Proposed here is enhancement to the Sakai calendar service implementations to afford multiplexing between the existing Sakai-local calendar storage and the proposed-for-development CalDAV-backed storage.

Not proposed: Event data migration from legacy storage

This proposal does not include a data migration path or automation for loading existing Sakai calendar data stored via the existing Sakai-local calendar event storage into the new CalDAV implementation.

Guiding assumptions

Assumption of post Sakai 2.5 Sakai project trunk

This proposal assumes this integration work is undertaken in the context of the Sakai community source project itself, with development targeted to post-Sakai 2.5 Sakai trunk. Development and code sharing will happen in a development branch (see SAK-13277 - Getting issue details... STATUS ) for this purpose.

Sakai added significant and relevant iCal support for the 2.5 version. While CalDAV is not exactly the same thing as this iCal support, there's significant alignment between CalDAV-enablement and iCal-enablement. As such it is anticipated that some of the existing iCal-enabling enhancements will be re-sable for the proposed effort and the task would be more difficult in an environment without these iCal-enabling enhancements. In theory the enhancements developed under this proposal could be backported to Sakai 2.5 or even to earlier Sakai versions. That backporting is not included in this proposal.

Zimbra CalDAV is a "beta" feature

Zimbra CalDAV is a "beta" feature of ZCS 5.0. This proposal and estimates allow some time for investigation of Zimbra as a suitable test target and reference implementation backing store for the CalDAV features proposed here, but it is assumed for this estimate that Zimbra CalDAV is sufficiently working and featureful that there will not be major impediment to using it to develop and test the CalDAV features. Major issues with this approach discovered during the course of this effort will be communicated during the course of this work and it is possible that the beta-nature of this functionality will impede this effort, with exploration of an alternative backing store (Bedework?) a possible workaround. In any case, what is proposed here is a good faith effort to develop and test CalDAV features to be developed in Sakai against CalDAV features existing at a beta level in Zimbra ZCS 5.0, with commitment to communicate effectively about issues encountered.

  • No labels