[dev] [commits] Horde branch master updated. f8e4ae158a913be0e58c22d489101e197f4248b0

[Michael J Rubinsky]

On Jun 30, 2011, at 12:03 PM, Jan Schneider <jan at horde.org> wrote:

> 
> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
> 
>> On Jun 30, 2011, at 3:46 AM, Jan Schneider <jan at horde.org> wrote:
>> 
>>> 
>>> Zitat von "Michael J. Rubinsky" <mrubinsk at horde.org>:
>>> 
>>>> The branch "master" has been updated.
>>>> The following is a summary of the commits.
>>>> 
>>>> from: 49f6fd0ccea39dd1c751dfc6611c70e01e82bdc0
>>>> 
>>>> f8e4ae1 Allow syncing of multiple owner-owned calendars.
>>>> 
>>>> -----------------------------------------------------------------------
>>>> 
>>>> commit f8e4ae158a913be0e58c22d489101e197f4248b0
>>>> Author: Michael J Rubinsky <mrubinsk at horde.org>
>>>> Date:   Thu Jun 30 00:47:05 2011 -0400
>>>> 
>>>>   Allow syncing of multiple owner-owned calendars.
>>>> 
>>>>   Events from all owner-owned internal calendars can now be included
>>>>   in syncing operations. Controllable via user pref. New events on
>>>>   sync clients will always be added to user's default calendar...and there
>>>>   is no visual distinction of different calendars on the client
>>> 
>>> Awesome! What's the reason for only allowing synchronization of user's own calendars though?
>> 
>> It's mostly to avoid problems with multiple copies of the same event in different calendars. Could probably filter these out while sending and only allow editing the copy on the user's own calendar in this case, but that adds a lot complexity and overhead for querying for duplicate events on each sync transaction.
>> 
>> Another reason - since the calendar is not owned by you, access might change in the future. If you are suddenly given read only access, or even have your access removed, you still have copies of the events on your device. The user would need to know enough to remove the sync state via the Horde UI (or reset the account on the device) to force a folder refresh (or a slow sync in syncml).
>> 
>> Also, since there is NO way on the client to indicate multiple calendar sources, no distinction between sources, it wouldn't be obvious that an event is not an event on one if your own calendars. I know this reason might seem a bit weak, but I feel it could cause confusion if viewing a number of non-owned calendars along side each other.
> 
> None of these have been real-world problems in Turba so far.

Though in Turba, you wouldn't have multiple copies of the the same uid in multiple address books from different users, right? Sending the same uid value to the client multiple times as an ADD operation does not have a defined outcome (at least in AS). It most likely would just overwrite the existing copy of the event (though when I played with this previously, one client I tested ignored the second entry, while others replaced the first with the second).  Also, what happens if User B edits his copy of an event that is owned by User A? Since User A is watching User B's calendar for changes, that change will get picked up and sent to the device, altering User A's copy of the event to now match User B's.

To further expand on the last point from my previous email... If User A and User B both have frequently occuring events titled something like 'office hours' or 'work', there is NO way to tell which event belongs to which user. In the Horde UI, at least we have colored calendars, or even the ability to toggle the calendar off and on to declutter the view.  In the device, there is no such visual cue, and you can't deselect a calendar to view using the device's UI, since according to the device it is all one calendar. It would be far too easy to confuse these events.  With Turba, at least, you have the potential to have more information to go on, even if two contacts have the same display name (phone number, address, email etc...). 
 
While none of these may have caused issues with Turba, or probably won't be a problem _most_ of the time with events, I think the potential for confusion/data corruption is too high to allow this. This is already more than Exchange itself allows ;)


Mike

> 
> 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