There's even a way for users to put blocks of free-busy time into this system that don't correspond to events (or that correspond to private events that the user does not wish to share): The client can upload "blank" events (these are called VFREEBUSY components) to the CalDAV server, and these are included in the report.
One of the benefits of the server generating the report is that it can do so for only a day or a week period under examination. A peer-to-peer or dumb-storage solution (without server logic) requires the clients to upload and download larger chunks of free-busy information (although I'm not sure there's sufficient evidence of real performance problems in that depending on how clever we make the publish algorithm).
Another benefit is that in the long run there are good signs that this will be the standard solution, workable not just for Chandler <--> Chandler but also to get free-busy information for Sunbird users with known CalDAV server locations, or to use a CalDAV gateway that extracts free-busy information out of an Exchange system.
I believe this is a pretty expedient thing for us to do even in 0.6 -- it makes free-busy information available for download with little more upload work than we already do, and it does require some server support but I think we can do that. There are certainly arguments against relying on server logic -- the added dependency for the schedule in 0.6 for example -- and we can well hash those out as well as the benefits.
http://ietf.webdav.org/caldav/
Thx, Lisa
On Feb 11, 2005, at 11:58 AM, Bryan Stearns wrote:
After a brief conversation with Mimi and Sheila this morning about free/busy, I had an idea and wrote it up here:
http://wiki.osafoundation.org/bin/view/Journal/FreeBusyStrawMan
Comments welcome.
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
