Scheduling Phase 1 spec review

Present : Jeffrey, Alec, Sheila, Mimi, Philippe (note taker)

Spec reviewed : Scheduling-0.7.html

Objective of Phase 1 :

• Make one calendar free/busy or the whole MyCalendar
• On the server, you can choose one calendar or the whole set of published calendars (roll up) as the basis of the free busy info

Eventually, Chandler will publish .ifb files to Cosmo

Use case :

• Publish 1:1 mapping of "My Calendar"
• Publish subset limited to 1 collection

Issue : publishing "My Calendar" and other calendars will create sync issues with non Chandler write clients (e.g. Scooby) that do not understand Chandler's way of having events appearing in several collections. For those clients to maintain free busy, they'll need to publish an event in 2 calendars.

One way around (somewhat) : create a subfork in CalDAV to post Mine and not Mine calendars and create the free busy info from the Mine node/set of collections.

Debate on using roll up :

• We think that the only thing that's not too confusing is to do a 1:1 mapping between "My Calendar" and "free busy".
• That will solve issues with 3rd party shared events that the user considers "Mine".
• Looks like the real solution (not for Phase 1 though) is to store one ifb per account.
• The ifb will be computed from the My Calendar info on Chandler.
• The menu item "Publish free/busy" will share "My Calendar" under the hood and use that as the basis for fb on the server.

Issue with "per account" : possible issue with Sphere in the future.

Issue with ifb :

• Need to be updated everytime something is changed
• ifb can be quite big so this translates in perf issue
• People who are having their calendar managed by someone else won't get the ifb info updated as long as they don't sync
• Should we extend Cosmo to do more than just CalDAV and understand "Mine" for instance with some special data?
• Things we do beyond CalDAV won't be cross compatible with other CalDAV servers (e.g. Oracle CalDAV server)