[Kolab-devel] freebusy creation for multiple calendars per user

[Bernhard Reiter]

[ Some more details about the draft. ]

On Saturday 04 September 2004 00:17, Martin Konold wrote:

[Draft rev 1.1]

> Partial fb

> 1. We add to the Kolab Format Specifiction a new annotation which allows to
> express that we want a pfb for this folder.

This would be an imap annotation.
Also it would not be specific to a users, but only to the folder itself.

> 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. 

As "group" is used below then I get to believe that the rules are proposed
for group and shared folders.

> 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.

Martin further explained to me:
	Shared folders are in contrast to users/groups not belonging to any mailbox.
	They are more like anonymous folders. If we decide that calendars in shared
	folders shall be relevant for the fbs of users having read access to the
	shared calendar then the only useful semantics is to check the participants
	of the events in this shared folder. Please note that for participants also
	dls can be used.

he also continued about the extra effort:
	This does not mean much extra effort. When creating a fb we must parse the	
	complete calendar anyway.

Thinking more about this, I think despite the consistancy problem (in some folders
the participants are looked at and in some they are not) this has more problems:

	+ It is not directly clear what users a participant directly corresponds to.
        A distribution list or delegated address might have used. 
       Also the participant was invited in some case so that status must be taken into
	consideration

	+ When triggering a recreating of a sharedfolders pfb, it must be found out
	which users have read/write permissions and a pfb must be written within each
	of their pfb caches. For shared folders with a lot of users, this is getting a bigger operation
	also it would mean to have give write permissions to all the users that also have write
	permissions on the shared folders to the personal pfb store.

To address these problems I have made the other proposal,
where the existance of files in the personal pfb cache 
(called a "webfolder" in my other email) indicate that a folder is relevant
for the fb list. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/devel/attachments/20040908/341a9a2c/attachment.p7s>