Hi Helge, --On July 28, 2008 4:42:55 PM +0200 Helge Heß <[EMAIL PROTECTED]> wrote:
>> The freebusy URL work being done by CalConnect will allow >> specification of a date/time range as query parameters on the URL. > > Yes, most servers support such query parameters. (btw the format > should be selected by the HTTP accept header?) Accept is a valid option, but I may want to explicitly give you a URL and tell you to use one particular format, so encoding that in a query parameter is handy. Of course it is optional. > Anyways, in the far majority of scheduling cases it doesn't really > matter. Freebusy info which goes a year into the future is usually > useless (except for VIPs who are really booked for a year ahead :-). The time-range can be used to fine-tune the request to only get information over the range that is important at that time. > IMHO the vCard+ifb solution is pretty good from a real world > perspective, the wished-for timerange can be selected once in the IFB > URL of the contact. (say /users/sjobs/cal/freebusy?range=PT1Y for some > CEO and /users/hh/cal/freebusy?range=PT4W for me ;-) > We don't even need query-para standards for that (though its nice to > have). Well that depends. Sure, servers can set a default time range when one is not present, and so no query parameters are needed at all, but having a little more control over that is handy. That is certainly what we have been told by some people operating internet-based freebusy services. Standardizing the query parameters (and perhaps more importantly what the value format) is important for interoperability - particularly if we expect to see more clients using this. >> It is true that the CalDAV Access freebusy-query REPORT is limited >> to a single calendar and thus is not useful in a true "scheudling >> scenario" At that point the CalDAV schedule VFREEBUSY REQUEST is the >> appropriate solution. > > I don't know. Such scenarios only work well if all attendees use > CalDAV servers, ideally the same server system. Or the local CalDAV > server would need to act as a proxy/gateway which is also suboptimal. > IFB-GETs are cross-domain, cross-server and already work just fine > with a lot of deployed systems. Actually a lot of published freebusy information is just a static file generated by a client or server and published on an http server. As such it does not represent a real-time view of a calendar user's actual free time. When it comes to scheduling meetings with a lot of attendees having accurate data for all, real-time gets to be important. > Same goes for iMIP vs CalDAV scheduling IMHO. > Also IMHO its not really something which needs to be optimized. If I > plan a meeting with 10 people, thats 10 trivial, Squid'able HTTP GETs. > So what? :-) Well there is a lot more to it than that and this is probably not the best forum to go into all the issues. -- Cyrus Daboo _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
