[Kolab-devel] Free busy information

[Bernhard Reiter]

On Wednesday 01 September 2004 15:23, Bo Thorsen wrote:
> On Wednesday 01 September 2004 14:42, Bernhard Reiter wrote:
> > On Tuesday 31 August 2004 10:58, Stephan Buys wrote:
> > > My honest opinion about this is that the only real practical way to
> > > do this is to let the server handle all the FB lists for Calendars
> > > hosted on it...
> >
> > That is not the real question
> > as the partial free busy list would be collected on a server
> > and it is possible for many partial free busy lists to generated them
> > on the server, too.
> >
> > > This would mean some sort of daemon that generated FB lists upon
> > > request. or maybe a daemon that updates FB files whenever a change in
> > > a Calendar is detected (can be accomplished with the IMAP IDLE
> > > extension).
> >
> > The problem is, that this does not solve some situations:
> > 	 - The user has a local calender
> >        (or a calendar on on a completley different server)
>
> There is no groupware solution that can handle this, so I would not have
> any problems with Kolab not doing it either.

It is not requirement for Proko2, but if we can have a design
that is open for this in the future, it would be to our benefit.

> >         - we cannot find out which calendars the user has read access
> > to should be in his freebusy list.
>
> This use case is not one I can accept as a showstopper.

This was meant as showing why you cannot indirectly determine 
which folders should be considered for freebusy list creation.
This potentially leads to a major usability problem unless
you look at each appointment and consider all participants.


> > > We can also add a "Private/FB-Only/Detail" annotation to all Calendar
> > > folders. The client would be able to specify the "policy" for the
> > > Calendar (FB-Only being the default), the daemon would then honor the
> > > policy according and accordingly show:
> > > 	1) Nothing - the Calendar is private
> > > 	2) Only "Start-End" times - FB Only
> > > 	3) Details of an event - Detail/Extended FB
> >
> > This does not work, because this is only one flag for many users
> > and the folder will only be relevant to some of them.
>
> It is possible to mark some folders with this information if we have to.
> That is not a difficult problem to solve.

The problem as you also aknowledge below is that this 
information would be binding for all users of a folder.
That is not enough.


> > The client is the only one in this game that has the full control
> > and information about what folders should be considered for a users
> > freebusy list.

> > The problem is to save the vector of this information somewhere
> > and then how to do the workflow of other people being able to update
> > some folders.
>
> And this is exactly the problem. While it sounds simple, it is in fact
> *incredibly* difficult. 

And this is were the pfb list suggestion has a nice solution.
We have one webdirectory (with subdirectories) per user.
The pfb collector runs through it and collects all pfbs.
If there is a pxfb, it uses it and if there is a referal, it follows it.

This is my idea of the vector and it is completely client controlled,
but server updated.

> I'm *very* reluctant to try and implement this so
> late in the game for proko2/kolab2.
>
> In fact I expect that I would need at least a months development to do
> this :-(

No you are thinking again that the client would need to create something.
If you only need to request one URL after uploading something to a calendar
folder with user credentials, this should be able to be done in a few days.

> > The Kolab design explicitely does behond the non-scalable database
> > approach of those servers. The idea of partial free busy list continues
> > to make this possible for even more sources in a consistant way
> > preserving the simple design that the clients keep control and do most
> > of the work.
>
> And I'll sacrifice this design in FB lists any day, since asking for these
> is not something that is done several times per second.

This is not a performace issue, but one of privacy and control.
The client needs to be in control and there is no reason to not 
have it more than one calendar source.

> The absolutely only showstopper I can think of is a security issue with
> doing it.

This is not the main issue. The problem is that a powerful "freebusy user"
would not solve the vector issue and the latter leads to the usability problems.

Think about a section boss having read write to three calendars and 
severn more on read only. 
He only wants to monitor six out of the read only ones,
but one has important and frequent company board meetings.

So the 4 out of 10 calendars are relevant for his  freebusy list.
If we leave the board meeting calendar out, this is a siginicant problem.
If we include the 6 read-only project folders, this also makes his
freebusy information almost useless.

-------------- 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/20040902/ea851cdc/attachment.p7s>