[dev] Allow syncronization of multiple calendars with SyncMl

[Gonçalo Queirós]

Citando Jan Schneider <jan at horde.org>:
> 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.
It seems that Outlook assumes that if you don't send a calendar
identifier, than you moved the event. While this is not correct for sure
since the RFC doesn't specify that, i think you agree that the current
behaviour is not desirable also.
The question is if its better to play along with Outlook (since the RFC
doesn't specify anithing about calendar/event relation) or let it as is.
>> 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.
I don't think you can syncronize calendars that someone shared with you at
the moment (at least on the Kronolith sync pref the shared calendars don't
appear), so we can enforce a per account unique name, or we can think in
another solution.
>>>> - 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/
>
>   --
>   Horde developers mailing list
>   Frequently Asked Questions: http://horde.org/faq/To unsubscribe,  
> mail: dev-unsubscribe at lists.horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 53 bytes
Desc: not available
URL: <http://lists.horde.org/archives/dev/attachments/20120131/5791c573/attachment.vcf>