Free/Busy in Chandler 0.7

Cosmo

• freebusy query already working on one collection, so testing against one collection should already work
• .ifb files can just be stored in non-Calendar collections, so Chandler's not really blocked, or likely to be in the future, by many Cosmo features

Cosmo work relating to Chandler 0.7

• freebusy query on multiple collections
• freebusy access ticket
• query about what access a ticket gives

Future Cosmo work

• Understand VFREEBUSY, so freebusy report includes them

vobject

• add VFREEBUSY support (trivial)

Chandler phasing

Share (out)

• .ifb file in the home collection
  • per collection, or just all?
  • Perhaps not necessary on Cosmo, because freebusy query is preferable and Brian thinks this is a small to medium amount of work
  • necessary for non-CalDAV servers. Is this an important 0.7 use case?

Share (in)

Early phase

• Internal representation of a freebusy block
  • Just use event, perhaps add a freebusy flag?
  • freebusy collections have to be read-only
• Just GET a static .ifb, to start, using existing sharing workflow
  • Will require a slight tweak to the ICalendar sharing layer, this falls in between Grant's world and Jeffrey's (and Morgen's!), Jeffrey will do this

Later phases

• issue freebusy query (returns equivalent content to .ifb)
  • There's no cache control mechanism for freebusy reports
  • Is it important for freebusy information to be available offline?
  • How often should freebusy requests be made? For what time periods?
  • Should responses be persisted, or should a new request be made every time freebusy is viewed?
    • If requests are made when freebusy is viewed, ui may be slow
• Option of per collection freebusy, if this is even desirable

Questions

• Might it be useful to offer UI to force an imported collection to be read-only or freebusy, even if the ticket supports a higher level of access?
• Is it useful to offer freebusy URLs per collection (especially if the above UI option is offered)?
• VFREEBUSY supports more states than free and busy (free, busy, busy-tentative, busy-unavailable), should the full range be rendered? How?
• Where does UI for publishing freebusy live?
• Is it important for freebusy information to be available offline? Is a pause for online report responses acceptable?

Possible future features

• Ability for users to create freebusy block, different from empty event
• mode that highlights free times, automatic when freebusy is selected or overlaid, but doesn't obscure collection/text data about events actually, I'd like to do this in 0.7, but I haven't heard if it's a requirement

Links

Scheduling Spec

Spec review meeting notes - 030606