[dev] Allow syncronization of multiple calendars with SyncMl

[Jan Schneider]

Zitat von Gonçalo Queirós <goncalo.queiros at portugalmail.net>:

> Citando Jan Schneider <jan at horde.org>:
>> Zitat von Gonçalo Queirós <goncalo.queiros at portugalmail.net>:
>>> Hi there dev.
>>>
>>>   Attached is a patch that changes the Kronolith API so its possible to
>>>   synchronize multiple calendars between Kronolith and Outlook, and
>>>   respect the calendar-event relation.
>>  This is already possible, technically, though I understand the
>> difference of your approach.
>>> I used the Funambol connector, so some code is only related with Funambol.
>>>   The code is not 100% perfect, since there are some minor issues (some
>>>   times you need to sync twice to actually sync), but i hope to fix that
>>>   next week.
>>>   I'm very interested in knowing if you guys think this can go to the code.
>>>
>>>   The major features are:
>>>   - Respect the event/calendar relation.
>>  Not necessary, because we already search for the events' UIDs in
>> all calendars.
>  From what i tested, if you have multiple calendars on Outlook, all those
> calendars events will be syncronized with Kronolith main calendar.

This is correct for client-to-server synchronization.

> The problem is that as soon as you edit one event on the Kronolith, and
> you sync, it will be moved from the original calendar on Outlook to the
> main calendar.

That's Outlook's (or the plugin's) fault then though.

> This is not desirable at all, since the user will end up with all is
> outlook events on the outlook main calendar.
> The patch respects the event/calendar relationship and doesn't move the
> event to the main outlook calendar if the only thing we did was edit it on
> Kronolith

But that doesn't work reliably either because there *is* no  
calendar-event-relation using UIDs. That's why using labels is fragile.

>>> - Automatically creates the calendars on Outlook/Kronolith when
>>>   synchronizing
>>  This is an interesting idea. Do you have any
>> numbers/ideas/experience how relieable the X-WR-CALNAME and
>> X-FUNAMBOL-FOLDER attributes are?
>>  The problem I have with that approach is, that those are calendar
>> *labels*. They can be changed, and they are not necessarily unique.
> No, i don't have numbers, i looked at what Funambol exported/imported and
> worked with that.
> Outlook doesn't allow repeated calendar names, but Kronolith does, so
> either we disallow it on Kronolith, or we have to find another way to fix
> this.

Disallowing won't work, because you can always get permissions on a  
shared calendar at a later point with a conflicting name. And of  
course we cannot require globally unique calendar names.

>>> - Move an event between two calendars on Kronolith, will also update the
>>>   info on Outlook (event move between calendars in Outlook is not possible)
>>  This already works, because moving an event adds a "delete" and an
>> "add" entry in the history storage.
> Yes, but since Horde is not exporting the event calendar, it wouldn't do
> nothing apparently, because the event only changed calendars.
> With the patch, the event will actually change to the correct calendar on
> Outlook
>>> - Rename the calendar on Outlook/Kronolith, will update the other side
>>>   calendar name
>>  How does that work, i.e. how do you know the original calendar?
> Funambol sends both calendar names, but since we load the event using its
> uid, we know the original calendar. Next, we just compare if the original
> and current calendar are different to check if we need to update the event
> calendar
> When the user changes the name of a calendar in Kronolith, we add a
> 'modify' entry for all the events on that calendar, which will make it
> sync all of them the next time.
>>> - All add/delete/edit are synchronized, no matter to what calendar the
>>>   event belongs to
>>  Already works.
> True, but with the problem already pointed out
>>> Possible drawbacks:
>>>   - Removing a calendar on Kronolith/Outlook will only erase all events
>>>   from that calendar on the other side, not the calendar itself
>>>   - I didn't tested with recursive events (although there's some code
>>>   specific to these kind of events), so i don't know yet if they are
>>>   synchronizing, no matter the calendar they belong to.
>>  Do you mean recurring events?
> Yes
>
> Also worth noting, that currently there's an issue with syncronization,
> that im trying to fix, and it might cause other issues with the patch i
> provided.
> I will provide another patch for that issue, since its actually a
> Kronolith bug
>
> Thanks


Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/