[Dev] Re: [Cosmo] Free/Busy in Chandler 0.7

[Philippe Bossut]

Hi,

I really like the concrete simple example to sustain this thinking. It 
helps tremendously. My comments in line.

Jeffrey Harris wrote:
> Here's the complex use case we want to support.  Marilyn's sidebar looks
> like this:
>
> * My Calendar
> * Work (mine, published to cosmo-demo)
> * Home (mine, published to cosmo-demo)
> * Sally's soccer practice (mine, subscribed to, not on cosmo-demo)
> * Events managed for Lorenzo (not-mine, published to cosmo-demo)
>
> Marilyn's free/busy should be derived from "Work" + "Home" + "Sally's
> soccer practice" + a few items appearing only in "My Calendar".
>
> Possible Solutions
> ==================
>
> A) Publish My Calendar, use it for free/busy information
>
> This works, but it means that a change to "Home" has to be uploaded
> twice.  Also, a change to "Home" made by a non-Chandler client might
> take a long time to propagate to the free busy information.
>   
Same delay for "Sally's soccer practice" calendar. Basically, anything 
that can be done outside the Chandler client won't be seen on My 
Calendar as long as the originating Chandler is relaunched and reconnected.
> 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.
>   
Except for the perf aspect (module recurrence issues), this has the same 
drawback that A), i.e.: the originating Chandler client needs to be 
launched and connected so that the new info can be computed and uploaded.

It's a limitation but one that I think is something we can live with, 
except for those rare people who do have their schedule organized by 
someone else (an assistant for instance) and do rarely connect themselves.
> C) Use a rollup free/busy report on the home collection.  Maintain a
> special "events in My Calendar not otherwise published" collection,
> containing the events in Sally's soccer practice and any other events in
> Marilyn's My Calendar not otherwise appearing in her Cosmo home collection.
>
> This still has problems.  "Events managed for Lorenzo" will be included
> in Marilyn's FREEBUSY, which we don't want, so:
>   
-1, this clearly does not work...
> D) Same as C), but create a mine collection and a notmine collection on
> Cosmo, putting all calendar collections but "Events managed for Lorenzo"
> in mine.
>
> The annoying detail about this is, what happens when Marilyn moves to
> part-time and decides "Work" should no longer appear in her My Calendar?
>  The collection needs to be moved from mine to notmine, resetting all of
> the ETags on resources in "Work", making sync really slow.
>   
Yes but that happens rarely so I don't see that as a deterrent if the 
rest of the solution is consistent. That being, said, implementing some 
Chandler semantic (mine/not mine) in a hierarchical way is asking for 
trouble. For instance, a Chandler user can pick an event in a "not mine" 
collection and move it to a "mine" collection making it mine in the 
process (e.g. one of those "Events managed for Lorenzo" meeting is a 
meeting that you are going to attend). Chandler does not duplicate that 
meeting. I'm not sure how the sync works right now (does the event 
appears in both collections?). If the event is not duplicated, this 
won't work.
> E) Apparently semantics will be added to CalDAV in the next month or so
> that setting a particular property on a calendar collection will prevent
> events in that collection from being included in free/busy reports.  Use
> those when they're implemented in Cosmo.
>
> In this scenario, Chandler just won't support Marilyn publishing "Events
> managed for Lorenzo" in her own account without screwing up her
> free/busy until Cosmo adds these semantics, but that's not a crucial
> 0.7alpha2 use case, and there's a reasonable path between here and there.
>
> This scenario still suffers from free/busy not being perfectly up to
> date if "Sally's soccer practice" changes, but at least changes to
> "Work" and "Home" are reflected immediately in her free/busy
I have the same question than for D here: what happens to those events 
in a "not mine" calendar that are actually "mine" (because I said so)? 
May be Morgen can answer that one.
> Conclusion
> ==========
>
> As you might guess, I think we should do E).  This means creating a
> "Publish my Free/Busy information" menu item which creates an "events in
> My Calendar not otherwise published" collection (more reasonable name
> suggestions welcome) which gets published along with other collections.
>
>   
I like it E too except for these mutants events that are moved in 
Chandler from a "not mine" to a "mine" collection. If this is not a 
problem, I actually prefer E to B because of its "almost always" 
up-to-date aspect. Otherwise, I'd prefer B. (so waiting for Morgen to 
shed some light on the subject).

Note thought that all of these solutions suffer with "Sally's soccer 
practice" (subscribed, mine but not published collection). I can't see 
one solution though short of moving the subscription logic to Cosmo 
(Yikes!) so that free/busy can be computed based on update to this 
remote calendar. Since that doesn't seem like a feasible feat, I suppose 
that delay in updating free/busy in that case is tolerable.

Cheers,
- Philippe