--===============0259904540==
Content-Type: multipart/signed; boundary="nextPart1217283.urOeIpA5Xg";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1217283.urOeIpA5Xg
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi all,

There has been some discussion about constructing FB lists lately, and we=20
have identified a problem with them.

In Kolab 1, it was fairly simple - when the user changed the calendar, he=20
uploaded the FB list to the server. Unfortunately in Kolab 2, this won't=20
be enough.

Consider this:

Person1 runs Kontact and person2 runs Outlook. They both use Horde=20
occasionally for web access.

Person1 has one IMAP folder and one local file containing calendar=20
information.

Person2 just has an IMAP folder.

In addition to this, both are part of a working group that has it's own=20
calendar IMAP folder, and they both have read-write access to this.

Whenever Person1 changes his calendar, he has full knowledge about all=20
folders, and can upload the FB list. However, if it's the group folder he=20
changes, he is actually modifying Person2's calendar also.

Also, when Person2 changes the group folder, he changes Person1's=20
calendar.

The problem does not exist, if it's not required that freebusy lists show=20
some reasonable data. Basically this is a tradeoff between easy to=20
implement (one person still only uploads his own fb lists) and accurate=20
(with person2 on holiday, the calendar could be wrong for a long time).

=46or lots of servers, there is no option to do the accurate but tricky way=
=2E=20
But for the Kolab 2 project we need to at least have the option to have=20
accurate fb lists.

There is actually a third option: If it's required to keep all calendar=20
stuff in IMAP folders, we would have a possibility to make an FB list=20
creation daemon on the server that would construct the FB lists from the=20
IMAP folder info. We have PHP code that can do this (needed for=20
car/room/... resources anyway), but it's not a good solution. At least=20
for Kontact, it's possible to connect to a lot of different servers, you=20
can have calendar info in several local files, and more. And having a=20
daemon with rights to read all calendar folders sounds like a big=20
security issue.

Bernhard Reiter (I think) came with the idea of partial free busy lists=20
(PFB). The idea is that the user has one pfb for each calendar info=20
place. So in the above scenario, Person1 has three pfbs: the personal=20
IMAP folder, the local file, and the group pfb. The requirement then is=20
that if you change something in the calendar, the pfb of it needs to be=20
uploaded.

When the user requests an FB list, the server will run a script that=20
collects the pfbs and returns a full FB list (and caches it). This script=20
is easy enough to write.

The concept sounds easy, but it's technically not simple to do. And it=20
needs support from at least all Kolab clients.

Now, to just complicate matters even more, it's quite possible that people=
=20
will start monitoring shared calendars - for example the secretary will=20
have a lot of folders visible, so he can know when the different groups=20
are meeting and so. But he should not get these folders contents added to=20
his FB lists. For this to work, we need a way for the user to make a=20
folder (or local file or ...) with a flag that this shouldn't be used for=20
=46B lists.

So, what do you think. Do you agree that pbfs is the only solution that=20
solves all the involved problems? Is it over engineered? Do you have a=20
better idea? Stuff like this is what we need to get solved the right way,=20
for Kolab (with Kontact/Toltec/Horde...) to be a real integrated=20
solution.

I would like to get some feedback on this before I start working on a way=20
to implement it, so comments are highly appreciated,

Bo.

=2D-=20

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klar=E4lvdalens Datakonsult  |   Denmark

--nextPart1217283.urOeIpA5Xg
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQBBMufMmT99lwfUS5IRAi8oAKCTbxoE7UJUjQOQOazTf8b6HNXf4ACg3BOf
Mn+EjYmxRo2W8lDmYL6GM4E=
=PG40
-----END PGP SIGNATURE-----

--nextPart1217283.urOeIpA5Xg--

--===============0259904540==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
--===============0259904540==--