Skip to end of metadata
Go to start of metadata

I am getting a fairly clear sense of how CalDAV clients and servers communicate with each other. I even read the spec! (Interesting aside, one of the primary authors of the CalDAV specification is Lisa Dusseault, who is a star character in "Dreaming in Code," the story of the Chandler project. She comes across as the smartest and sanest person on the team).

Here are the design questions I am currently mulling:

  • Will the calendar store be configured Sakai-wide, per worksite, or per user per worksite?
  • How should the configuration be done?
  • How do we map between Sakai users and calendar server users?
  • What happens with a Sakai guest user who may not have a calendar server identity?
  • No labels


  1. I'm not sure I have understood this reflection, but if I have I feel strongly that the right model is like google calendar. I would want a site calendar for each worksite and a calendar for me. I would then want a client that allows me to combine calendars. When I am in a worksite I would want to be able to view the site events alone (for clarity) or against my personal events and/or all my events (for conflicts and alerts). I would also probably want some meta-calendars e.g. allmycourses, allmyclubs, but I am less sure how often I would use them. Your probably thinking of something more technical to do with configuration than this, but I wanted to say it anyway

  2. Your last question is a challenging one. Is it architecturally possible to use the provider model, where a guest would use local data storage (SAKAI_USER) and the institutional user info comes from external provided data? In the case of the calendar, assuming an external calendar server like Zimbra, guest users would store data in the OOTB calendar server (Bedework?)?

  3. There's a use case that's very interesting to me that's currently out of scope of the work you're doing, but I at least wanted to throw out there as it might inform how things are set up:

    • Instructor has shared office hours for all her courses
    • Instructor wants to expose these office hours to all her courses at once, such that any changes that are made propagate to all course schedules automatically.
    • Instructor does NOT want n copies of the same office hours showing up in their "My Workspace" calendar (the current model if all course schedules get the office hours)

    Assuming this desired functionality, here's ONE possible way to map calendars and users:

    • Instructor has a separate personal calendar (as John Norman suggests, separate calendars for separate concerns) called "Office Hours"
    • Each of the Instructor's course sites has a unique calendar user (where these are stored is a question) for events specific to that course (class meeting times, assignment due dates, etc.)
    • The calendar user for each course site subscribes read-only to Instructor's "Office Hours" calendar

    This could get tricky when you bring the student "My Workspace" into the mix. Since the "Office Hours" is just a subscription of the course user but not in the course site calendar itself, would the student be auto-subscribed to the "Office Hours" as well, or would they be shown a "meta-calendar" (to borrow from John again) where the Sakai services aggregate the data for him? If it is a subscription, what would happen when subscribing a student to the calendar multiple times, in the case where a student has more than one course from Instructor?

  4. If I understand the "configuring" questions, you're saying that the external calendaring application has some flexibility in how it wants to arrange Sakai events by calendar. This seems a different question from how those events are received, but it may be that a conflation is necessary or helpful for things like performance.

    I don't think a per-user-per-site configuration stands up against the Google pattern John highlights, but also because this is not how Sakai thinks of calendars. There seems to me greater risk of a broken UX in the external calendar app if the site calendar is not the basic unit of event organization, at least as far as what's being communicated from Sakai (I can imagine Zimlets that might start to do clever things with the site calendars once received, but that's in a different scope).

    I had imagined that guest users would have only the Sakai experience of the calendar (within the site in question), and that the external calendar app would be content to simply fail to share the calendar with those it didn't recognize.

  5. Zach, for the configuration store, when you say "per worksite", does that also imply each individual's site, their My Workspace? That would help support Google Calendar like behaviour; similar to how Calendar Summary already enables one to bring things together from multiple calendars. The missing piece perhaps then is having more than one calendar per worksite, as you can create as many calendars for yourself, and share them with different permissios, as you want in Google Calendar.