Private groupware objects
Bernhard Reiter
bernhard at intevation.de
Mon Feb 27 15:23:19 CET 2006
The problem of the "access" choice in Outlook's GUI still needs to be solved.
Let me try to summarize what we have.
I have spend some time with Martin on the phone
going through the various possibilities.
There apparently is agreement that security must be enforced
on server side and that we do not get far with encryption.
Given the technical differences, I believe it will be quite hard
to make Outlook accept different calendar folders fully
in the near future. So this road will not lead to a solution soon.
This leaves two principle approaches:
a) Joon's proposal of extending the IMAP protocol.
b) The principal idea of using an addition folder and merging
the results for Outlook. Originally proposed by Martin,
but with some variations by others.
Both would solve the problem on the server.
a) Enchance IMAP Protocol: Will create a lot of work in the area
of the IMAP standard and on the implementation side of Cyrus.
Advantage: It is less work on the clients.
b) More work for the clients.
The best suggestion here I have seen would be to :
Use a completely second namespace for a private tree that is modelled after
the regular tree. It has the advantage that the ACL for the owner could
later be enforced by the serverfor this namespace.
Also the KDE client could display these extra folders
just like regular folders, while only Outlook would need to merge it.
Joon, Johannes: Do you think b) would be technically feasable for you?
My next question would be:
Is this something for a Kolab Format/Concept 2.1 or 2.2?
I would say yes, because it is a bit of development.
Bernhard
More information about the format
mailing list