FreeBusy in Kolab 3.0
From Kolab Wiki
Contents |
Definitions
- Simple Free/Busy (SFB)
- Free/Busy information that contains nothing but a users status, displaying the user as free, busy, tentative, out of office.
- Extended Free/Busy (XFB)
- Free/Busy information that contains the Simple Free/Busy information, plus the headings of events. Read access should by default only be available for properly authorized, specific users.
Capabilities
Upon completion to the fullest level, the new free/busy system should provide the following capabilities / address the following scenarios:
Requests to the server
- Standard retrieval scenario
- A local client (e.g. the calendar interface in the web client) or remote client (e.g. Kontact running on a desktop) request the free/busy information for user X by HTTP(S). The server must apply the correct policies to determine whether to require authentication, and based on the result of authentication and application of ACLs, whether to respond with the SFB or XFB information for this user.
- Depending on the design of the server and the way in which the information is generated, this may or may not involve ad-hoc regeneration of cached free/busy information.
- Relay retrieval scenario
- A (local or remote) client requests free/busy information for a user that is not a user on this server. The server should now;
- Look up the MX record for this email address & retrieve the remote server address
- Attempt to contact the remote server with known free/busy URLs and access methods
- Retrieve the free/busy information from that server and relay it to the client
- For Step 2 it should use all methods available under the Aggregation retrieval scenario to allow obtaining useful information in own-party (another server in the same company) as well as any party (an unrelated third party also using groupware and thus providing free/busy) scenarios.
- Aggregation retrieval scenario
- A remote server (e.g. another Kolab server, or an MS Exchange Server of any generation) requests the local free/busy information for user X as input to its own free/busy generation process. This information must not include third party/external calendars to avoid infinite loops of servers querying each other, may or may not require authorization, and authorization may decide whether the request is answered by XFB, SFB, or access denied.
- Regeneration of free/busy information
- It may be necessary to have a URL against which the user authorizes to trigger regeneration of free/busy information on the server in order to ensure proper information protection.
Logic / Settings
- Local calendars to include in free/busy
- Which calendar(s) should be used in free/busy generation?
- Remote calendars to include in free/busy
- Which calendar(s)/uri(s) on which server(s) with which authorization should be included into the user's local free/busy generation?
- Access policy
- Should free/busy be available without authorization? Which kind? SFB? XFB? If authorization is required, is it sufficient to access XFB, or just SFB?
Basic functionality
Basic functionality for the first generation of this service must include;
- Standard retrieval scenario,
- Regeneration of free/busy information,
- Administration of which calendars to include in free/busy,
- ACL / Access policy for XFB & SFB,
which only needs to be concerned with Kolab 3.0 based groupware data.
Advanced functionality
Advanced functionality will be the
- Relay retrieval scenario
- Aggregation retrieval scenario
which shall both allow integration of third party groupware solutions, including proprietary solutions, and thus the data retrieval modules will need to be re-usable between these scenarios and should be sufficiently intelligent to manage detection of the respective service and usage of the correct free/busy retrieval approach.
Some Random Notes
Generating Free/Busy Information
The Kolab 3.0 server must generate free/busy information, including correct recurrence calculation, for each user's calendar as well as shared calender folders on a server. This information must be cached on the server, as regeneration for each individual request would likely cause severe performance issues.
Storing Free/Busy Information
Possible scenarios for storing this information is in a specific XML object, in a specific sub-folder for each calendar, in a specific folder hierarchy, in a specific folder, or in a server side database (file or SQL). Each of these options has advantages and disadvantages that must be considered and the choice is unfortunately not yet quite clear.
Aspects to consider: Off-line functionality? ACLs?
