private groupware objects

[Joon Radley]

Hi Bernhard,

> Joon,
> can you explain in more detail why the suggestions of 
> http://kolab.org/pipermail/kolab-format/2006-February/000649.html
> are not feasable?
> Those are the best I have seen so far.

It is the worse possible hack. Yes it can solve this problem, but there are
a number of other problems introduced.

1) It is not even remotely back wards compatible.
2) Every existing server will have to be cleaned out to allow for the
rebuild of data.
3) Each client in an organization will have to be upgraded at the same time,
missing one can introduce data corruption.
4) It will lead to a one object on the client to multiple objects on the
server and this in different folders. This breaks the one-on-one object
mapping model which means that every client will have to rewrite their
synchronization engine.
5) Folder mapping will have to be rewritten in each client.
6) Changing of access from private to non-private and visa versa, will mean
a rebuild of the client side folders and structures.
7) Problems in object synchronization where a user has write access to a
folder but not privacy access. Changing a normal object to a private object
by this user creates objects that are out of sync. Any changes made to
existing private marked objects will only be reflected in "public" folder
and not the private folder. So everybody that has access to the "public"
folder will see the changes and the original user will not see them.

In summary it is major effort and nightmare to implement, a total migration
disaster both client side and server side and synchronization pit falls.

Yes, theoretically it can work, but is totally impractical.

Best regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za