Hi Helge, --On July 28, 2008 4:42:55 PM +0200 Helge Heß <me@helgehess.eu> 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