Handling of private/confidential groupware objects
bernhard at intevation.de
Mon Jan 23 09:51:27 CET 2006
Am Mittwoch, 11. Januar 2006 17:16 schrieb Martin Konold:
> Am Mittwoch, 11. Januar 2006 16:37 schrieb Bernhard Reiter:
> > Am Mittwoch, 11. Januar 2006 13:00 schrieb Martin Konold:
> > > I therefore want to repeat my proposal with the "hidden" private
> > > subfolder.
> > I repeat my criticism of your proposal
> Please elaborate your final criticism in an easy to digest manner so that
> we can discuss it in a more structured way (I fail to fully understand your
> points from rereading this thread)
Will do, but as you could see, I am a bit slow with this. :/
My criticism boils down to:
- adding a hidden folder semantic, will make things
more complicated especially for other clients.
Together with access control, this means less security.
- We need to solve the reminder issue for other folders anyway,
otherwise we never get over this Outlook limitation. As we need
to solve this anyway on the connector side, this even might be
less work in the end.
> > and propose that Outlook connectors implement reminders
> > and we treat the flag as "sensitivity".
> OL knows about reminders but is limited to the primary calendar.
True. I think it might be feasable to implement reminders for
other calendars based on the incidences-for annotation
(as described in the Kolab-Format document).
> this semantic will also break all PDAs (Pocket PC and Palm). I therefore
> conclude that your proposal is not an option because we have no means to
> change the PDAs.
I guess that most PDAs will not know about several calendars and
will disregard some options that Outlook(+connectors) and the KDE Kolab Client
can deal with. The only way to solve this in my opinion is to
somehow establish a connection from the appointment saved
to the smaller device and the mapping of capabilities.
My personal folder appointment will be saved to the PDA only calendar,
but getting the category "personal folder", so that syncing it back will
put it in the right folder.
> > The Outlook way of enforcing this in the client
> > can be used as another reason to explain this change
> > to users.
> Yes, but my proposal would solve the issue in a doable and secure way while
> keeping the well established semantics working.
I agree that it is doable,
for the reasons above I think that doing it differently will be even
more secure, because of a structure which is easier to understand
More information about the format