event XML 1.1 (fix recurrances)

[Martin Konold]

Am Montag, 29. Januar 2007 09:06 schrieb Joon Radley:

Hi Joon,

> What part of "a new object is created" do you not understand? The moment
> you hit step 4 a second object is created with the new attendees.

Sorry, I don't understand. The procedure as described below refers to the 
_old_ xml format. 

I claim that with the old format this problems happens as the old format does 
not allow to express a change in attendees. The only way to express this is 
to create a new object. 

As your connector does not prevent the user from changing the list of 
attendees for an exception in a series the problem is real.

With the new format you have a chance to express this series as a single XML 
document including all exception incl. changes in the list of attendees.

> In the current exception structure only supports deleted recurrences. This
> works 100% between Kontact and Toltec.

Yes, but how do you deal with the case that a user indeed changes the list of 
attendies within a series. The OL GUI definetly allows for this.

In case you decide to create a new XML document for this change you could do 
the very same with the new proposed format. Why is the new format a step 
backwards?

I would be very grateful if you find time to answer Q1-Q4 as repeated below.


> > 1. Alice enters a weekly recurring event with attendees in
> > the calendar of her boss Bob using OL/Toltec Connector.
> >
> > 2. This event is synchronized to the Kolab server using the
> > old XML format.
> >
> > 3. Bob, who happens to be a KDE Kontact user is
> > reading/synchronizing his calendar folder.
> >
> > 4. Alice then changes one attendee for the third occurance in
> > Outlook. (To my knowledge Toltec Connector does not prevent
> > the user from doing this and this operation is offered by the
> > Outlook GUI to the user)
> >
> > 5. From an Outlook and Alice's end users point of view the
> > operation (changing an attendee) was perfectly legal and
> > successful. After all this change is reflected correctly in
> > the user interface.
> >
> > 6. According to your observations the newly created exception
> > is now separated ("creates a new object") from the original
> > recurring event.
> >
> > 7. Then Toltec Connector tries to synchronize the modified
> > event including its recurrance rules and its newly introduced
> > exception date to the server
> >
> > Q1: How does the Toltec Connector deal with this situation today?
> >
> > Q2: How is step 4 expressed in the generated XML using todays
> > Kolab XML Format?
> >
> > Q3: What will KDE Kontact see after step 7?
> >
> > Q4: In which respect is the old format superior to the new proposal?
> >
> > > He has somehow published
> > > a new standard of the Kolab-XML format that totally breaks
> > > interoperability between the existing clients.
> >
> > How does the new format break interoperability?
> >
> > (I claim that assuming your observations are correct that the
> > interoperability was already broken before!)

Regards,
-- martin

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Stuttgart - Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/
-------------- 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/format/attachments/20070131/75e0e134/attachment.sig>