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

[Martin Konold]

Am Mittwoch, 8. September 2004 16:36 schrieb Bernhard Reiter:

Hi Bernhard,

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

Yes, yes

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

What do you mean? I want to say that groups are handled very much like foreign 
users while shared folders are a little bit different. After all this allows 
to cover more use cases. If the fb policy for group calendars does not fit a 
shared folder with a slightly different policy can be very handy.

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

I don't understand this.

>        Also the participant was invited in some case so that status must be
> taken into consideration

If it is an event with invited participant then this calendar entry is 
irrelevant for the fb creation because accepting an invitation means makeing 
an entry in the users calendar. The fb information is then already present in 
the users calendar.

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

Yes, provided that the fb annotation is set for every user having read 
permissions a pfb must be created. (Please note the Kolab write permissions 
include read permissions implicitly)

> For shared folders with a lot of users, 
> this is getting a bigger operation

Yes, this is the reason why there exist the possibility to not set the fb 
annotation. After all this all depends on the use case you try to model.

IMHO in most cases group calendars are more appropriate than shared calendars.

> 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 be more precise "to the personal pfb store for this specific folder". 
Security wise this is no big deal as the person in question is already 
granted to write this calendar. So beeing allowed to write the 
corresponding/derived pfbs is imho no big issue.

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

This is not a sufficient definition because it does not determine how the 
initial files get there. 

Regards,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold at erfrakon.de