thomas: doc/architecture freebusy.txt,1.20,1.21
cvs at kolab.org
cvs at kolab.org
Wed Apr 2 17:42:44 CEST 2008
Author: thomas
Update of /kolabrepository/doc/architecture
In directory doto:/tmp/cvs-serv29292
Modified Files:
freebusy.txt
Log Message:
space/tab cleanups
Index: freebusy.txt
===================================================================
RCS file: /kolabrepository/doc/architecture/freebusy.txt,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -d -r1.20 -r1.21
--- freebusy.txt 27 Mar 2008 17:01:56 -0000 1.20
+++ freebusy.txt 2 Apr 2008 15:42:42 -0000 1.21
@@ -7,20 +7,20 @@
fb freebusy list
pfb partial freebusy list
-xfb extended freebusy list
-pxfb partial extended freebusy list
+xfb extended freebusy list
+pxfb partial extended freebusy list
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 within time overviews.
+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 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
+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.
@@ -31,7 +31,7 @@
User folder Calendars
-A user may have several personal folders in his account. One Folder is called
+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
@@ -43,9 +43,9 @@
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. A group as opposed to a user shall be used to give
+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. 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.
@@ -56,11 +56,11 @@
Multi-Group Calendars
-On a Kolab server there may be several "shared folders" containing calendars.
+On a Kolab server there may be several "shared folders" containing calendars.
Technically those folders are like "anonymous" user accounts
and a better name might be "multi-group folders".
-Their indented use is to include a larger number of people,
-like all members of a company.
+Their indented use is to include a larger number of people,
+like all members of 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
@@ -74,14 +74,14 @@
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
+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
+1. We add to the Kolab Format Specifiction a new annotation which allows to
express this folder is freebusy relevant. (The annotation should
ideally also make that folder alarm relevant.)
@@ -99,7 +99,7 @@
user/group1/calendar (1, fb)
user/group2/myhierarchie/calendar (3, fb)
-If a client changes the contents of one of those calenders,
+If a client changes the contents of one of those calenders,
it must trigger the creation of the pfb and pxfb as described below.
This will be done with the credential of the user that has
write permissions.
@@ -111,13 +111,13 @@
attribute kolabFreeBusyFuture which is stored in the LDAP directory and a
globally configurable constant kolabFreeBusyPast. While the former is
defined for the kolabInetOrgPerson LDAP objectclass the later is stored in the
-kolab objectclass. As all calculations are done on the server the resulting time
+kolab objectclass. As all calculations are done on the server the resulting time
is always calculated relative to the servers local timezone.
pfb cache
-The pfb and pxfb are written to the account's pfb cache hierarchy.
+The pfb and pxfb are written to the account's pfb cache hierarchy.
user1/user1/calendar.pfb
user1/user1/anotherhierarchy/calendar.pfb
@@ -127,9 +127,9 @@
If a calendar folder is removed the corresponding pfb must also be removed.
-Actually the term pfb cache is a little bit misleading as it actually is an
-intermediate store which does not only cache the results of pfb trigger processes
-but which implicitly also defines which pfbs are relevant to create the user specific fb.
+Actually the term pfb cache is a little bit misleading as it actually is an
+intermediate store which does not only cache the results of pfb trigger processes
+but which implicitly also defines which pfbs are relevant to create the user specific fb.
Triggering pfb
@@ -138,41 +138,41 @@
https://servername/freebusy/trigger/user1@domain.tld/calendar.pfb
https://servername/freebusy/trigger/group1@domain.tld/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
+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 pfbs.
-To trigger creation of a pfb (and the corresponding pxfb at the same time),
+To trigger creation of a pfb (and the corresponding pxfb at the same time),
issue an HTTP GET request like:
https://servername/freebusy/trigger/X/PATH/FOLDERNAME.pfb
-
+
with X being one of
- a) primary email address
+ a) primary email address
Clients triggering for folders of other users could derive
this from the corresponding imap path component = name
- and then adding "@maildomain" to it.
+ and then adding "@maildomain" to it.
b) the uid
c) the corresponding imap patch component of the user name
(the server will try to add @maildomain to it.)
- and PATH and FOLDERNAME being UTF-8(*) encoded IMAP foldernames.
+ and PATH and FOLDERNAME being UTF-8(*) encoded IMAP foldernames.
d) any valid email alias
-All pfbs are readable for every (authenticated) user
-though normal users don't require to read the pfbs
-but the pfb collector must be able
+All pfbs are readable for every (authenticated) user
+though normal users don't require to read the pfbs
+but the pfb collector must be able
to read all pfbs from potentially many servers (multi-location setups).
-The pxfb are only readable
-by users having read permissions on the corresponding folders.
-Creation of pxfbs happens together with the pfb creation.
+The pxfb are only readable
+by users having read permissions on the corresponding folders.
+Creation of pxfbs happens together with the pfb creation.
One successful trigger does both.
In general all clients writing to calendar folders on the server
-must trigger the generation of pfbs. This include KDE Kontact,
+must trigger the generation of pfbs. This include KDE Kontact,
the Outlook Clients, the web client and the resource manager.
-They must trigger after one or more write operations to one folder.
-If a clients knows that it will do several write operations
+They must trigger after one or more write operations to one folder.
+If a clients knows that it will do several write operations
during a very short interval to one folder,
it should delay the trigger until it has done the operations
to avoid unnecessary triggers.
@@ -180,10 +180,10 @@
Pfb collector
Another script with different credentials (also being able to act
-without further rights) needs to collect the pfbs
+without further rights) needs to collect the pfbs
to create the real freebusy list.
-If a freebusy list is requested the script can just
+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.
@@ -205,10 +205,10 @@
https://servername/freebusy/trigger/X/PATH/FOLDERNAME.pfb
After calling the pfb script the Kolab client may immediately delete the emtpy
-folder.
+folder.
On the other hand the server side pfb creation script MUST be able to
-handle empty or unexisting calendar folders. A trigger call to an unexisting
+handle empty or unexisting calendar folders. A trigger call to an unexisting
or empty folder leads to deletion of any traces related to this folder in the pfb storage.
(*) It is the job of the pfb creation script to convert the UTF-8 encoded
More information about the commits
mailing list