bernhard: doc/architecture freebusy.txt,1.1,1.2
cvs at intevation.de
cvs at intevation.de
Wed Sep 22 18:24:08 CEST 2004
Author: bernhard
Update of /kolabrepository/doc/architecture
In directory doto:/tmp/cvs-serv30034
Modified Files:
freebusy.txt
Log Message:
Complete overhaul, based on my talks with Martin and proko2 clarifications.
(Done from memory in a hurry, so might be rough; but is better than nothing.)
Index: freebusy.txt
===================================================================
RCS file: /kolabrepository/doc/architecture/freebusy.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- freebusy.txt 3 Sep 2004 22:14:05 -0000 1.1
+++ freebusy.txt 22 Sep 2004 16:24:06 -0000 1.2
@@ -1,18 +1,24 @@
-***** initial draft *****************
+How to handle freebusy lists for Kolab2
+Draft
+$Id$
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.
+describing the free and busy times of a user.
+The fb is mainly used together within time overviews.
+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.
+There is a use for a group account with three people having access
+and a folder that should contain events that are just written -- not invited.
+To be useful for this the events would need to be freebusy relevant.
+
Types of Calendar folders.
@@ -32,24 +38,33 @@
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.
+permissions. A group as opposed to a user shall be used to give
+folders to several users on an equal level. Each folder has an admin,
+which is the person which can give out rights to the folders.
group1/calendar (1, fb)
group1/myhierarchie/calendar (2)
group2/myhierarchie/calendar (3, fb)
group2/otherhierarchy/calendar (4)
-Shared Folder Calendars
+Multi-Group Calendars
-On a Kolab server there may be several shared folders containing calendars.
-Technically sf are like "anonymous" users accounts.
+On a Kolab server there may be several "shared folders" containing calendars.
+Technically those folder are like "anonymous" users accounts
+and a better name might be "multi-group folders".
+Their indented use is to include a larger number of people,
+like all members a company.
+Multi-group folders will not be relevant for freebusy lists.
+The reason is that within larger groups of people almost never all
+of them have to be at an event. E.g. it is better to work with invitations
+or a more specific group folder when wanting half of the company to a meeting.
shared/calendar (1)
-shared/ahierarchie/calendar (2, fb)
+shared/ahierarchie/calendar (2)
shared/anotherhierarchy/calendar (3)
shared/yetanotherhierarchy/calendar (4)
+
Partial fb
Whenever a client writes to a calendar it MUST trigger the server based
@@ -60,50 +75,38 @@
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
+express this folder is freebusy relevant. (The annotation should
+ideally also make that folder alarm relevant.)
+
+Existance of the annotation:
+ for user folders: relevant for the fb of the owner
+ for group folders: relevtant for the fbs of the people with read access
+
+
+E.g. in the notation and the example above we have fb flags
+on the following folders:
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.
+If a client changes the contents of one of those calenders,
+it must trigger the creation of the pfb and xpdf as described below.
+This will be done with the credential of the user that has
+write permissions.
-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
+The pfb and xpfb are written to the accounts pfb cache hierarchy.
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
+group2/myhierarchie/calendar.pfb
If a calendar folder is removed the corresponding pfb must also be removed.
@@ -112,16 +115,47 @@
On the server we use mod_rewrite to parse URLs like (needs more thought!)
https://servername/group1/group1/calendar.pfb
+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.
+All pfb are readable for every (authenticated) user.
+The xpfb are only readable by users having read permissions
+on the corresponding folders.
-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)
+Pfb collector
+
+Another script with different credentials (also being able to act
+without further rights) needs to collect the pfbs
+to create the real freebusy list.
+
+If a freebusy list is requested the script can just
+simply have to recursively get all pfb under the users fb cache hierachie
+and then the ones in the group calendar folders which the user
+can read and which are marked fb relevant.
+
+If an extended freebusy list is requested, the script has to use the
+given credentials of the users to try to access the xpfbs in the same way.
+If access to the xpfb is not possible, use the corresponding pfb.
+
+
+Future
+------
+
+For the future scheme could eventually be extend towards:
+
+ - make it possible for clients to upload the pfb instead
+ of just triggering the creation.
+ Advantages: Put load on the client.
+ - add referal type files for the cache hierachy that
+ make the collector script search for an pfb elsewhere.
+ Advantage: Client could use other servers or local files for fb, too.
+
+ - add a deep parsing mode for the multi-group folders
+ that creates pfbs by looking into all appointments
+ and copies them to a special place in the cache hierarchy.
+ Possible advantages: Easing the modelling of lager groups.
More information about the commits
mailing list