bernhard: doc/architecture freebusy.txt,1.23,1.24

[cvs at kolab.org]

Author: bernhard

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

Modified Files:
	freebusy.txt 
Log Message:
Minor Clarifications:
* fixed typo "patch", the "path" was meant.
* moved the footnote closer to where it is referenced
* rephrased the paragraph that explains that only one pfb trigger is enough
Minor reformatting to fit 79 chars width.


Index: freebusy.txt
===================================================================
RCS file: /kolabrepository/doc/architecture/freebusy.txt,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -d -r1.23 -r1.24
--- freebusy.txt	17 Jun 2008 07:13:55 -0000	1.23
+++ freebusy.txt	25 Sep 2008 09:23:40 -0000	1.24
@@ -112,8 +112,8 @@
 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
-is always calculated relative to the servers local timezone.
+kolab objectclass. As all calculations are done on the server 
+the resulting time is always calculated relative to the servers local timezone.
 
 
 pfb cache
@@ -139,13 +139,14 @@
 
 https://servername/freebusy/trigger/user1@domain.tld/calendar.pfb
 https://servername/freebusy/trigger/group1@domain.tld/calendar.pfb
+https://servername/freebusy/trigger/user1/subfolder/Calendar.pfb
 
 We use SSL secured basic authentication for transferring 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),
-issue an HTTP GET request like:
+A successful trigger request will lead to the creation of both pfb and pxfb.
+Thus only one trigger is necessary and this is an HTTP GET request:
 
 	https://servername/freebusy/trigger/X/PATH/FOLDERNAME.pfb
 
@@ -153,13 +154,17 @@
 		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.tld" 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.
+		c) the corresponding imap path's component of the user name
+		   (the server will have to add "@maildomain.tld" to it.)
+		   and PATH and FOLDERNAME 
+		   being UTF-8(*) encoded IMAP foldernames.
 		d) any valid email alias
 
+(*) It is the job of the pfb creation script to convert the UTF-8 encoded
+paths and folder names into the imapd specific naming conventions.
+
 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
@@ -213,8 +218,6 @@
 handle empty or not existing calendar folders. A trigger call to a not existing
 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
-paths and folder names into the imapd specific naming conventions.
 
 Future
 ------
@@ -224,7 +227,6 @@
 	of just triggering the creation.
 	Advantages: privacy issues if the calendar is stored somewhere
 	else, but a unified freebusy list is wanted.
-
 
 	- add referral type files for the cache hierarchy that
 	make the collector script search for an pfb elsewhere.