[horde] Active sync: multiple calendars?

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Gunnar Wrobel <wrobel at horde.org>:
>>>
>>>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>>>
>>>>> Quoting Andreas Ntaflos <daff at pseudoterminal.org>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> is it possible to access and sync multiple Horde calendars (on the same
>>>>>> user account) with the new ActiveSync plugin? Or is this not supported
>>>>>> by design or specification?
>>>>>
>>>>> By specification. The AS protocol does not support multiple  
>>>>> calendars for a single user.
>>>>
>>>> But shouldn't there be ways to aggregate calendars? I'm pretty  
>>>> certain the ActiveSync support on the Kolab server allows  
>>>> selecting several.
>>>
>>> Sure, it would be possible to essentially combine all events from  
>>> multiple calendars into a single AS collection. However, there are  
>>> a number of issues that I ran into while trying to do this when I  
>>> originally wrote the library:
>>>
>>> There is no way to differentiate the calendars on the client (AS  
>>> only supports a single "calendar" folder) so no calendar names, no  
>>> horde-centric calendar colors (in fact some clients might color  
>>> the events based on the tags) - all events look like they are in  
>>> the user's "main" calendar.
>>>
>>> There is no way to mark events as read only, no way to map back an  
>>> event to the calendar it came from in the case that multiple  
>>> calendars may have the same event uid (though this is not specific  
>>> to AS), and no way on the client to select the calendar to add a  
>>> new event to (all events are assumed to be on the user's "main"  
>>> calendar). This last point _might_ also cause issues with both  
>>> event invitations and recurring event exceptions on calendars  
>>> other than the user's "main" calendar (don't have code or protocol  
>>> docs in front of me at the moment to verify this one).
>>>
>>> There would also be issues when a user changes which calendars  
>>> they want included after the initial setup (would basically  
>>> require the user or admin to explicitly reset the AS account to  
>>> force a complete replacement sync). For example - a user initially  
>>> sets up two calendars, but then decides to remove one. All the  
>>> events from the second calendar will still be present on the  
>>> device. Similarly, adding a second calendar would not sync the  
>>> events that were created/modified prior to the last successful  
>>> sync time.
>>>
>>> Yes, some of these issues could be at least partially worked  
>>> around by e.g., limiting the calendars allowed to be synched to  
>>> calendars owned by the user, or adding user pref for the calendar  
>>> to use when creating new events on an AS device, but these rather  
>>> feel like hacks instead of implementations.
>>>
>>> If in fact kolab does allow this, I'd be interested in both how  
>>> the kolab/activesync connector implements this and how robust this  
>>> actually is. If you have any links to code or similar, I'd love to  
>>> take a look. This is a sore point for me as well though even if we  
>>> get minimal support for this, would likely not help me since it's  
>>> calendars I have read only access to that I need to include (see  
>>> note above about read only issues).
>>>
>>> Also, it's worth noting that I'm aware that Google's "activesync"  
>>> support allows this - but this is not true activesync; they have  
>>> added features to the protocol and these only work if using a  
>>> Google client, not a generic activesync client.
>>
>> All what you said could be applied to contacts too, where we allow  
>> several sources. In fact, synching several calendars can be  
>> implemented transparently, i.e. for both SyncML and ActiveSync,  
>> analogous to address books.
>
> Except for the fact that the same event UID might exist in more than  
> one calendar, though I guess that would be fairly rare if we limit  
> to calendars the current user *owns* (which we have to do anyway).  
> As long as this doesn't muck up invitations and recurring  
> events/exceptions I'll add it to my list.

Invitations and duplicate UIDs are already broken in Kronolith anyway,  
this won't be different from using Kronolith directly or through a  
desktop client though. And of course this needs to fixed independently  
from AS.

See http://bugs.horde.org/ticket/8734 and http://bugs.horde.org/ticket/3965

Jan.

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