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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
