[Kolab-devel] Free busy information

[Bo Thorsen]

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.

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

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

> > Whenever you start to deal with shared resources/calendars the whole
> > client-based model starts to break down. I dont think we would ever
> > get a client based model to work 100%...
>
> 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.
>
> Creating of partial freebusy lists can be done on the servers
> where they are saved,
> but a client can have many sources and servers of calendar information.
> To allow this is an advantage of the Kolab (2) design.
>
> 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. 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 :-(

> > The way that MS-Exchange, Lotus Notes and Samsung Contact does it is
> > on the fly from the server...
>
> 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.

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

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20040901/b07f5036/attachment.sig>