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

[Bernhard Reiter]

Hi Martin,

On Thursday 09 September 2004 09:34, Martin Konold wrote:
> Am Mittwoch, 8. September 2004 16:36 schrieb Bernhard Reiter:


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

Maybe I am just confused what group calendars are.
Your draft was worded in a way that they were treated the same
as shared folders.

Actually as group calenders belong to the group, but
different people might have write permissions, we get the same
problem here that just the folder annotations do not clarify
for which of those users the appointments are relevant.


[parsing contents of a shared folder
 to find out for each appointment if it is relevant for a user. ]


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

I am saying that I fear that the algorithm that determines 
to who's fb list that event is relevant will be complicated
and not work in same cases. Like when a delegate
was invited or a public distribution list.

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

This leads to a modelling problem in that I actually ave write permission
to make the appointment for all the people involved as a group.
Then I do not want them all to get an invitation and have a second
copy of the appointment in their personal calendars.
E.g. when I am the section leader and later want to shift that appointment
slightly.

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

Using the referal pfbs we avoid creating several pfbs for each
users and looking at the participants in each event.

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

I see the same problems regarding the inclusion in the fb list for a user.

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

Ah, so you are thinking of having space for a folder
that will include the personal pfbs of each user that has read access to that folder?

I was more of thinking that each user as a personal pfb store
which will also include the pfb from the shared folders.
Otherwise at pfb collection for a user it would always check
all shared folders for a user specific pfb.

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

It was implicit from my postings:
The client put in the files initially on request of the user.
It can also remove them.
For shared folders a simple web interface for adding removing could be enough
for the start.

Bernhard
-------------- 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/20040909/0228d3c3/attachment.p7s>