"I'd like to share why I feel supporting "free-busy" and
"invite" is so important. I've been working in places where
Outlook/Exchange was heavily used. I was not a heavy calendar user
before but, once in these organizations, I maintained a full calendar.
Most of it was actually filled up automatically: I'd accept/reject
invites and things would get magically updated."
=====
BASIC INVITATIONS WOULD BE MORE USEFUL AND EASIER TO IMPLEMENT:
"I'm thinking that very basic, useful invitations would be a lot
easier (in terms of hours of labor) than a useful free-busy
implementation - we've done most of the work in 0.5 and 0.6 for simple
invitations anyway.
To make free-busy really useful requires a lot more work:
I just think there's a lot more to it
beyond just the display of the free time, to make it very useful -
there's coordination with a bunch of contacts - do we pop up a dialog
that allows users to add people from an address book? do we even have
an address book? How do we determine which users are on which WebDAV
server? Do we record THAT in an address book, if we have one? Then once
an appropriate free window has been decided, how do we schedule the
meeting?"
=====
INVITATIONS ARE MORE USEFUL THAN FREE-BUSY
FOR EXTRA-GROUP SCHEDULING:
"Personally, and this is VERY personal - I
find simple invitations more useful because I tend to schedule my
personal events with people that aren't on my calendar server
(especially since I don't have one :)) - It would be far more useful to
me, who schedules much more outside of my workgroup, to just send out
invitations.. be it in the form of VCF (which outlook understands) or
ICS, I don't care... then if I can launch chandler from thunderbird
with a VCF/ICS attachment, and chandler would ask "Which calendar would
you like to put these events in?"
I know there are all sorts of standards
around this (iMIP? I dunno) but the fact that outlook already does
things like VCF attachments, made me aware of how simple basic
interoperability could be."
=====
INVITATIONS ARE UNDOUBTEDLY AN IMPORTANT
PART OF THE SCHEDULING WORKFLOW, BUT THAT DOESN'T MEAN FREE-BUSY ON
IT'S OWN ISN'T VERY USEFUL.
Of course, these opinions aren't really
mutually exclusive. Whether free-busy or invitations is more or less
useful is highly personal. The "fundamental truth" that's emerging is
that both are critical parts of a single workflow: scheduling.
=====
COMPROMISE: LET'S THINK OF FREE-BUSY AS AN
EXPERIMENTAL FEATURE, perhaps supported by rudimentary
notifications/invitations, A FIRST STEP TOWARDS SUPPORTING COMPLETE
SCHEDULING WORKFLOWS:
"Given that, can we take an iterative
approach to this issue, build out some low-cost features that hint in
the direction of fully integrated scheduling workflows (ie. just be
able to view free-busy, but not be able to select a time, send out an
email ping from chandler, but not actually send out an event or be able
to manage acceptances and declines.)
I think even such small things could
dramatically enhance the calendaring experience and leave us wiggle
room to figure out what the next steps are based on user behavior."
=====
There was also a proposal for introducing
the notion of groups so that users could subscribe to all available
free-busy information for your work-group without having to enter a
separate URL for each work-group member. (See quoted text below.)
Lisa Dusseault wrote:
So the answer boils down to: yes, for members a cohesive
group that has their calendars hosted in the same place, each person in
that group will be able to use a single Cosmo URL to find their own
calendar and those of the others in the group. Beyond that, sorry.
You'll have to forgive my ignorance on WebDAV, but does it have any
concept of groups? i.e. if you can "look up" a user and ask for
view-free-busy, can you look up a group and get information about the
group?
The reason I ask is perhaps its possible to look up a group, and get
back a set of URLs that the client can go check for free-busy
information. So if you can look up "OSAF Apps" and get a set of URLs
that correspond to the members of the group, perhaps those URLs could
also refer to users/urls on other servers as well.
then it would be up to the client to merge this information
appropriately.
Alec
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation
"Design" mailing list
