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)
[EMAIL PROTECTED]
http://www.osafoundation.org

[EMAIL PROTECTED]
http://code-bear.com

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


Attachment: PGP.sig
Description: This is a digitally signed message part

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

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

Reply via email to