Free/Busy in Chandler 0.7

Hi Folks,

We're trying to work out a good plan for scheduling in 0.7.
 This email
is just about what free/busy information we make easily
accessible to
users and how we set that up on Cosmo, there's obviously
lots more about
scheduling to work out details on.

This summary is based on a flurry of off-list conversations
about
Free/Busy I've had in the last few days, starting with the
meeting whose
notes are at
http://wiki.osafoundation.org/bin/view
/Journal/SchedulingSpecReview030606.

So, onward!

Goals
=====

1) Provide free/busy info about individual collections
2) Provide "mine" free/busy info that matches
the events that appear
   in a user's All collection
3) Update free/busy automatically when non-Chandler clients
change
   events

Getting Free/Busy from CalDAV servers
=====================================

CalDAV servers can calculate free/busy information based on
the events
in individual calendar collections, or a "roll-up
report", returning
results based on all the events in all the calendar
collections
contained in a parent collection.

Challenges
==========

Goal 1) is mostly taken care of with basic CalDAV free/busy
reports.  We
need Cosmo to provide a ticket which only gives free/busy
report access,
and there's a bit of work to be done to help Chandler
figure out what
permissions a ticket gives (see
http://lists.osafoundation.org/pipermail
/cosmo/2006-February/000524.html).

At first glance, it seems easy to satisfy goal 2) with a
CalDAV roll-up
reports on a user's home directory.  Unfortunately, this
doesn't work
perfectly.  It assumes all a users' Chandler collections
are published,
and all the calendars published in the user's home
directory have "mine"
set.

Example
=======

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.

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.

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:

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.

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.

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.

Further input would be welcome!

Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

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
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

On Mar 7, 2006, at 9:21 PM, Jeffrey Harris wrote:

> 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.

I seem to remember that any scheduling system I used in the
past 
limited me to a fixed amount of time I could publish my
free/busy 
information to the outside world.  This type of limit is
probably 
acceptable to most users and would limit the scope.

>> 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.

+1 - free/busy should only be published for information that
I own

>> 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?

Could we not also publish free/busy to multiple locations
just like 
calendar information.  I tend to view free/busy not as a
part of the 
calendar(s) I maintain but as a totally stand-alone resource
that is 
published to either everyone or a known set of people.

---
Bear

Build and Release Engineer
Open Source Applications Foundation (OSAF)
bearosafoundation.org
http://www.osafoundation
.org

bearcode-bear.com
http://code-bear.com

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822
40B3 CD29


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

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
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

On Mar 12, 2006, at 4:14 PM, Philippe Bossut wrote:
> [...] 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).

Actually, as currently implemented, if you drag an item from
a 'not  
mine' collection and copy it to a 'mine' collection, that
event will  
not appear in 'My Calendar'.  In other words 'not mine'
currently  
trumps 'mine'.  The exception to this is if you drag an
item from a   
'not mine'  *directly* to 'My Calendar' -- in that case
it will show  
up in 'My Calendar'.  There is a discussion about changing
this  
behavior (making 'mine' trump 'not mine') in this bug: 
https:// 
bugzilla.osafoundation.org/show_bug.cgi?id=5368

> 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.

Regardless of mine/not-mine, if an event lives in two
collections  
within Chandler, and those two collections are published to
Cosmo,  
that event will be published twice (once in each Cosmo
collection).   
It's not really an exact duplicate necessarily because you
could be  
sharing reminders/status for one of those collections, and
not the  
other, so the .ics files representing that event could be
different.

~morgen


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

Hi,

Morgen Sagen wrote:
>
> On Mar 12, 2006, at 4:14 PM, Philippe Bossut wrote:
>> [...] 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).
>
> Actually, as currently implemented, if you drag an item
from a 'not 
> mine' collection and copy it to a 'mine' collection,
that event will 
> not appear in 'My Calendar'.  In other words 'not
mine' currently 
> trumps 'mine'.  The exception to this is if you drag
an item from a  
> 'not mine'  *directly* to 'My Calendar' -- in that
case it will show 
> up in 'My Calendar'.  There is a discussion about
changing this 
> behavior (making 'mine' trump 'not mine') in this
bug:  
> https://bugzilla.osafoundation.org/show_bug.cgi?id=5368
I forgot about that bug (or I assumed that we'll go with
making "mine" 
trump "not mine").

One thing that bug reminded me which is relevant to this
thread is that 
we want something for free/busy which is consistent with
what we do for 
minical. We don't want to explain to users how "My
Calendar" shows one 
set of event, "minical" is computed on another
one and "free/busy" a 3rd 
one... Delay in synchronization is hard enough to cope with
that we 
don't want to add difference in logic to the mix.
>> 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.
>
> Regardless of mine/not-mine, if an event lives in two
collections 
> within Chandler, and those two collections are
published to Cosmo, 
> that event will be published twice (once in each Cosmo
collection).  
> It's not really an exact duplicate necessarily because
you could be 
> sharing reminders/status for one of those collections,
and not the 
> other, so the .ics files representing that event could
be different. 
Interesting. So that being cleared, I'm inclined to favor
E) because of 
its better "Chandler off line" story (e.g. I
update my calendar using 
Scooby while on the go from a kiosk and everyone has an
updated 
free/busy to work with. That's cool...).

That being said, the word of caution on consistency made
above still 
holds. Something to think about for Jeffrey I guess.

Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev