martin: doc/architecture freebusy.txt,NONE,1.1

cvs at intevation.de cvs at intevation.de
Sat Sep 4 00:14:07 CEST 2004


Author: martin

Update of /kolabrepository/doc/architecture
In directory doto:/tmp/cvs-serv27002

Added Files:
	freebusy.txt 
Log Message:
Martin K.: Initial draft describing the concept of freebusy creation in case of multiple calendars per user using partial freebusy lists.


--- NEW FILE: freebusy.txt ---
***** initial draft *****************


Task

With Kolab we want to be able to generate and download freebusy lists 
describing the free and busy times of a user. The fb is mainly used together 
with gantt-charts. The most prominent use is when inviting people to an 
event.

Problem

With Kolab we offer the user many different calendar folders. The freebusy 
list of a user shall reflect the real situation as good as possible in order 
to provide a really useful hint to users.

Types of Calendar folders.

User folder Calendars

A user may have several personal folders in his account. One Folder is called 
the default folder. The default folder is used when accepting invitations.

The structure of user calendar folders is like

user1/calendar (1, fb, default)
user1/private/calendar (2)
user1/anotherhierarchy/calendar (3, fb)
user1/yetanotherhierarchy/calendar (4, fb)

Group Calendars

A group may have several calendars (often only one). Technically a group 
calendar is just a special user account with more than one user having access 
permissions. Group calendars are always handled like normal user calendars 
and the same rules apply.

group1/calendar (1, fb)
group1/myhierarchie/calendar (2)
group2/myhierarchie/calendar (3, fb)
group2/otherhierarchy/calendar (4)

Shared Folder Calendars

On a Kolab server there may be several shared folders containing calendars. 
Technically sf are like "anonymous" users accounts.

shared/calendar (1)
shared/ahierarchie/calendar (2, fb)
shared/anotherhierarchy/calendar (3)
shared/yetanotherhierarchy/calendar (4)

Partial fb

Whenever a client writes to a calendar it MUST trigger the server based 
generation of fb in the scope of the corresponding folder. We call these fb 
partial fb or pfb. The real user specific fb is then generated transparently 
to the requesting application on demand from the user specific pfb 
information.

The following rules apply:
1. We add to the Kolab Format Specifiction a new annotation which allows to 
express that we want a pfb for this folder.
This is used for user and group calendar folders. In the above example this 
will define that we generate pfb for

user1/calendar (1, fb)
user1/anotherhierarchy/calendar (3, fb)
user1/yetanotherhierarchy/calendar (4, fb)
group1/calendar (1, fb)
group2/myhierarchie/calendar (3, fb)
shared/ahierarchie/calendar (2, fb)

For shared folder calendars the situation is slightly more complicated. The 
same rule for the fb annotations applies but only those events which have 
user as a participant are used for the user specific pfb. In our example only 
the second shared folder calendar has the fb annotation requirement. All 
events of this shared folder get parsed and for _all_ participants 
corresponding pfb are created.

This means if for example 4 users (user1, user2, user3, user4) have access to 
the group calendar (group1/calendar) and a write or delete to an event which 
has user1 and user3 as participants happens then for exactly these two users 
new folder specific pfb are created.

In general only deletes and writes to calendars trigger the checks for pfb 
generation.

pfb cache

The pfb are written to the users pfb cache hierarchy. In our example the user1 
would have an hierarchy like

user1/user1/calendar.pfb
user1/user1/anotherhierarchy/calendar.pfb
user1/user1/yetanotherhierarchy/calendar.pfb
user1/shared/ahierarchie/calendar (2, fb)

If the user1 has also write access to a calendar folder (e.g. 
user2/user2/calendar) of user2 and user1 does indeed a write/delete operation 
to this folder and user2 chose to set the fb annotation than user1 triggers 
the generation of the pfb for user2. User and group calendars in contrast to 
shared calendars are always only the source for the pfb of the owning 
user/group.

group1/group1/calendar.pfb

If a calendar folder is removed the corresponding pfb must also be removed.

Triggering pfb

On the server we use mod_rewrite to parse URLs like (needs more thought!)

https://servername/group1/group1/calendar.pfb

We use SSL secured basic authentification for transfering the credentials to 
the server side code. The server side code then uses these credentials to 
access the calendar folders and to write the pfb.

All pfb are readable for every authenticated user.

In order to fetch all relevant pfb for a user for generating the users fb we 
simply have to recursively get all pfb under the users fb root folder. (This 
means that the folder structure implicitly contains the vector of relevant 
folders)







More information about the commits mailing list