Hi Morgen, >> 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" > collection. 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 simplicity. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
