[Kolab-devel] Kolab XML specification

Till Adam adam at kde.org
Thu Apr 21 08:29:59 CEST 2005


On Thursday 21 April 2005 07:20, Joon Radley wrote:

> > > is <scheduling-id>? Any unknown tag sould start with x-.
> >
> > The scheduling-id was introduced to the format (if it's
> > missing in the spec then Bo forgot about that, I'm pretty
> > sure it was discussed on the format list, at the time) to
> > solve a problem with the same incidence being in several
> > folders at the same time, all of them visible to the same
> > user. To avoid confusion with the incidence being there
> > twice, with the same uid, which violates the global
> > assumption that each event has a unique id, the concept of
> > separating the uid, which is globally unique, even for
> > identical copies of the same incidence in different folders,
> > from the scheduling id, which is the uid to be used when
> > scheduling this event (the uid of the "original" instance of
> > the event). That means that clients should use the scheduling
> > uid for all scheduling actions on the incidence as soon as it
> > is present, and use the uid as normal otherwise. The details
> > of how this came about and the different strategies discussed
> > to resolve the issue are to be found in the archives, I believe.
>
> The problem with this is that Horde assumes that that the subject line
> contains the <uid>. Toltec will also break your model, when the object is
> modified by Toltec it will write the <uid> to the subject and not the
> <scheduling-id>.

The invariant that the subject contains the uid, not the scheduling uid should 
still be maintained, I think. That's just an optimization, not something that 
the introduction of the scheduling-id needs to change. If it isn't 
maintained, then that's a bug somewhere in Kontact, I guess. I'll dig. I take 
it you are not currently writing scheduling ids? Has that discussion 
completely passed you by, for some reason, or do you actively think it's a 
bad idea? I wasn't exactly thrilled about it either, but now that we have it, 
all clients should honor it, I guess?

Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050421/90dc6893/attachment.sig>


More information about the devel mailing list