[Kolab-devel] Re: Non-unique UIDs

Bernhard Reiter bernhard at intevation.de
Tue Sep 28 11:55:07 CEST 2004


On Friday 24 September 2004 11:24, Bo Thorsen wrote:
> On Friday 24 September 2004 11:09, Reinhold Kainhofer wrote:
> > > Currently, KOrganizer has a very basic assumption that an event must
> > > have a unique UID.
> >
> > Yes, UIDs have to be *globally* unique, i.e. across all computers and
> > users.
> >
> > > Now consider this scenario:
> > >
> > > 1) Secretary and Boss both agree on a meeting invitation and get the
> > > event stored in the calendar folders.
> > >
> > > 2) Boss gives access to his calendar folder to the secretary.
> > >
> > > 3) Secretary now has two folders that contain an event with identical
> > > UIDs.
> >
> > But both events describe the same meeting.
>
> Yes, but they are not the same - when you are invited to some event, you
> don't get reliable information on what the other people have answered. So
> the two events could easily have different attendee responses set.
>
> > > We might be able to do 2), by changing the way we store an event. So
> > > when the user accepts an invitation, we make a new event with a new
> > > UID and keep the scheduling UID for reference. But I think this is
> > > more easily described than done.
> >
> > Yes, that will be quite hard to ipmlement. Imagine that the secretary
> > wants to send out an invitation for her bosses event. The uid needs to
> > be adjusted again before sending. And if she accepts, well, again, etc.
>
> So you think demanding the user to switch off their own calendar first is
> the only way to go?
>
> I would be inclined to agree.

I also tend in that direction, but thinking about a twist:
When displaying the overview, it seems easier to me to just
display one even twice, but when making changes (1) going into the editor
or accepting an update, the right folder could get the only one that is active?

When in doubt I believe that disabling the other folders is fine,
but we need a way to copy event from one event folder to another somehow,
so there must be some automatic support for switching those folder on an off
as far as I can see.

Just my 0.02 cents,
	Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/devel/attachments/20040928/d92f9056/attachment.p7s>


More information about the devel mailing list