Re: [CalendarServer-users] freebusy file url
Hello, The ifb file for compatibility might be a good idea but I think the biggest advantage of the report is that it lets you specify the date range. It also allows retrieving many FBs in one request. Which probably helps with client speed dealing with large meetings. Best regards, Kervin ----- Original Message ----
From: Helge Heß <me@helgehess.eu> To: calendarserver-users <calendarserver-users@lists.macosforge.org> Sent: Monday, July 28, 2008 9:35:35 AM Subject: [CalendarServer-users] freebusy file url
Hi,
does CalServer expose a regular GET'able freebusy URL for calendars?
like: GET /calendars/users/user01/calendar/freebusy.ifb
maybe even a merged view on principals: GET /principals/__uids__/user01/freebusy.ifb
I think that would be pretty nice. Its supported by many many clients and CalDAV vfb REPORTs do not really buy you anything in terms of functionality.
Thanks, Helge -- Helge Hess http://helgehess.eu/ _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
Hi Kervin, --On July 28, 2008 6:49:15 AM -0700 "Kervin L. Pierre" <kervin@adevsoft.com> wrote:
The ifb file for compatibility might be a good idea but I think the biggest advantage of the report is that it lets you specify the date range.
The freebusy URL work being done by CalConnect will allow specification of a date/time range as query parameters on the URL.
It also allows retrieving many FBs in one request. Which probably helps with client speed dealing with large meetings.
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. That can address multiple attendees and aggregates results for all the calendars the attendee owns. Our implementation of freebusy URL basically does the equivalent of the VFREEBUSY REQUEST behavior. -- Cyrus Daboo
On 28.07.2008, at 15:59, Cyrus Daboo wrote:
The ifb file for compatibility might be a good idea but I think the biggest advantage of the report is that it lets you specify the date range. 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?) 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 :-). 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).
It also allows retrieving many FBs in one request. Which probably helps with client speed dealing with large meetings. 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. 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? :-) Thanks, Helge -- Helge Hess http://helgehess.eu/
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
On 28.07.2008, at 17:32, Cyrus Daboo wrote:
Well there is a lot more to it than that and this is probably not the best forum to go into all the issues.
You are right. So if the freebusy-GET support would be added to CalServer trunk, it would be really great, otherwise we are going to emulate it using REPORTs. After all that was my original question, which got answered :-) Thanks, Helge -- Helge Hess http://helgehess.eu/
Hi Helge, --On July 28, 2008 6:34:35 PM +0200 Helge Heß <me@helgehess.eu> wrote:
Well there is a lot more to it than that and this is probably not the best forum to go into all the issues.
You are right.
So if the freebusy-GET support would be added to CalServer trunk, it would be really great, otherwise we are going to emulate it using REPORTs. After all that was my original question, which got answered :-)
Please feel free to add a ticket with that request so we do not loose track of it. -- Cyrus Daboo
participants (3)
-
Cyrus Daboo
-
Helge Heß
-
Kervin L. Pierre