[CalendarServer-users] freebusy file url

[Cyrus Daboo]

Hi Helge,

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