(I'm late chiming in on this - sorry.)
Morgen Sagen wrote:
I'm currently scoping out the following projects for 0.7:
A) Background synchronization (let the user continue to use
Chandler while syncing)
B) User Notification framework (provide the user some way to see
that shared items have been changed)
C) Conflict resolution (let the user manually reconcile
conflicting changes that have been synced)
Below is a brief description of each, including areas in which I
would need help from other groups (Andi with some repository work,
and the Apps team for some CPIA work). Comments are welcome.
(A) Background (or "asynchronous") syncing involves moving the
current sharing operations into their own thread rather than blocking
the main UI thread as they do today. The difficulty here will mostly
be in the repository view merging code, since using a different
thread requires using a different repository view. I expect I will
need some amount of Andi's time to work through view merging issues,
and we'll need some way in CPIA to indicate (probably via some
animated icon) that a collection is currently being synced. Grant
has already done an experiment with moving sharing to its own thread,
and I will incorporate that work soon. Some details to be worked out
here include what happens if the user is in the middle of editing an
item that is modified by a background sync.
Taking the small view of the simplest issue first....
This highlights the need for per-item change notifications: Ted, is this
still on your 0.7 list? (Currently, the detail view uses monitors to get
notifications about changes; monitors only fire for changes within the
same repository view. I'm hoping that the notifications will include the
attribute name, so I can only notify the attribute editors that care
about that attribute.)
As far as that last situation (user editing an item that a background
sync modifies), here's what'll happen if background sync and
per-item-attribute notifications are implemented, but we don't do
anything else to handle this case specially:
- Background sync brings in a new item into the background-sync
repository view, and commits the view's changes.
- The UI view is refreshed at idle time, which will fire change
notifications.
- The detail view will receive a notification that an attribute on the
displayed item changed, and reload that item's value.
This means that the user's edit will lose. Mimi, Sheila, and I talked
about this case when we were going over other 0.7 detail view issues,
and proposed changing things so that the user's edit would always win:
it's probably reasonable to consider the user's edit to be "newer" than
whatever was received in sharing, and this is potentially easy to do
(the attribute editor would just have to know when the control's value
had been edited, and ignore the notification if so).
If we need something more apparent to the user, it'd probably require
more state to be stored either in the item that'd been changed, or
passed along by the notification mechanism, but all that snowballs into:
(B) User Notifications: I'm not sure if I'm talking about what has
been referred to as "big-N Notifications", but clearly what is needed
for sharing is some way for the user to see a log of changes that
happened as a result of syncing. Currently you can see such changes
flash by quickly in the Sync dialog, but Mitch proposed the idea of
having a sidebar collection which acts much like an RSS feed of
changes. We could add a new Kind to the domain model named
"UserNotification" (or some name to distinguish it from any internal
notifications). Changes made in the background during syncing would
get a corresponding UserNotification item added to the Changes
collection. The user could then, at their leisure, scan through the
changes via the list view of that Changes collection, and either mark
each UserNotification as "read" or else delete the UserNotification
item. This same mechanism could be used not just for sharing-related
changes, but for any kind of thing that needs to be brought to the
user's attention in a non-immediate manner. These UserNotifications
could be fed into a single collection, or multiple collections,
depending on preference. This requires from CPIA: (1) a way to sort
the list view, and (2) some sort of 'mark as read' facility.
(C) Conflict Resolution: In 0.6, when two people change the same
attribute on the same shared item and synchronize, the first one to
sync wins. The second user gets a notification of the conflict in
the Sync dialog, but their local change is lost, overwritten by what
the first user assigned. There are a few approaches we could take to
provide better conflict resolution: (1) Quarantine all background
sharing changes until the user is at a point where they are ready to
incorporate all of those changes. The user is then presented with
each conflict (either one-by-one or altogether) and they choose from
either the local change or the remote change. All conflicts would
have to be resolved at this point, otherwise the repository could not
continue with the repository view "refresh". (2) Pick an automatic
conflict resolution policy ('local changes win' versus 'remote
changes win') and when a conflict happens follow that policy, but in
addition add a special kind of UserNotification
("ConflictNotification"?) item to the Changes/Notification log
collection, recording in it which Item/attribute had the conflict,
and what the two attribute values were. I prefer (2); this would
allow sharing-related changes to appear at any time (since from the
repository's standpoint, conflicts are resolved immediately), and
allow the user to review/resolve conflicts at their leisure. Ideally
reviewing a conflict would mean clicking on a ConflictNotification
item in the list view and being presented in the detail view with a
side-by-side comparison of an item -- local changes next to remote
changes -- and buttons allowing the user to pick between the two.
This project would require some CPIA work for presenting a conflict
resolution detail view.
Yikes (both from a UI and implementation standpoint :-) ). One issue
here is that syncing synchronizes individual item-level attributes, but
we don't always represent individual attributes to the user: some
item-level attributes turn into multiple user-editable things (eg, the
startTime holds the start date, the start time, and the timezone for an
event), as well as vice versa (eg, recurrence is stored in a whole
separate item, with multiple attributes determining the repeat pattern).
This indicates that we end up needing a way to present two detail views
side-by-side. For approach 1, we'd also need to teach attribute editors
to conditionally display the "local" or "remote" version of the item;
for approach 2, we'd need to teach them to incorporate newer values from
a UserNotification item. Either way, this mechanism also requires
support from the change-notification mechanism (since the detail view
uses the change-notification mechanism to communicate with itself), and
would require CPIA work to handle two rendered detail views at once.
(I'm sure there's more than this, but I'll wait until more work's been
done on an intended user-level design.)
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
