[Dev] Re: [Cosmo] Free/Busy in Chandler 0.7
jeffrey at osafoundation.org
Tue Mar 7 18:21:26 PST 2006
>> B) Chandler calculates free-busy based on what's in My Calendar and
>> periodically updates a collection of VFREEBUSY components.
>> VFREEBUSY components are more compact than full VEVENTs, so the
>> upload-twice problem is diminished somewhat. It still suffers from
>> non-Chandler propagation delays.
> +1, and I think a slight delay is not a big deal.
Hmm. I just realized I omitted another challenge associated with
VFREEBUSY. VFREEBUSY doesn't support recurrence, so recurring events
have to be expanded to some arbitrary distance in the future (a year or
two, perhaps). This means that I perhaps overstated the bandwidth
savings associated with publishing VFREEBUSY instead of VEVENTs.
> It's not clear to me how such a collection is computed. :-)
It'll be ugly, but I think it's at least well-defined. :)
> But since I am hearing that we will want Scooby to have access to our
> calendars even if we haven't shared them with others (which I guess
> makes sense), we're going to need to publish all our calendars to
> Cosmo anyway, so therefore we won't have to compute the "EIMCNOP"
Yeah, if/when that happens, how or whether we publish "EIMCNOP" will change.
> If/when Cosmo implements the 'free/busy collection
> property' feature you describe in E), then it seems like then you
> would want a checkbox within Chandler for each collection indicating
> whether or not the collection should be included in free/busy report
The idea is that in Chandler, choosing mine/not mine is the UI for
determining whether something is included in free/busy reports.
> One other thing to take into account is whether people will have
> their calendars distributed on multiple servers. I know I will have
> my work calendar on an OSAF cosmo instance but my personal calendar
> will likely be on my own cosmo, which means I couldn't use option E).
You would have to duplicate one of your calendars on one of your servers
to use E), or is there some deeper reason E) wouldn't work here?
> Also, in option B), does it need to be a collection, or would a
> monolithic ICS file do?
A monolithic ICS file would work fine. You'd have to rewrite the whole
thing every time anything changed, but that does have the virtue of
More information about the chandler-dev