Okay so I clarified from Morgen that 'comparing a Chandler user's
local version' with the version being pulled down from the server (in
this case the Cosmo user's version) ONLY HAPPENS, if the Chandler
user is trying to sync their changes at the same time. I guess
otherwise, you'd have to compare versions for every shared item, all
the time and that would take a looong time.
However, it seems like the only way a Cosmo user would unwittingly
overwrite a Chandler user's changes is if:
1. Cosmo user goes to view a shared collection.
2. Chandler user syncs change to an item in shared collection.
3. Cosmo user edits the item before their browser has a chance to
refresh to reflect the Chandler user's changes. (I'm assuming there's
no way to push a refresh from the server end if new changes are
detected in a shared collection?)
How likely is this to happen given our usage scenarios for Preview?
This is what I understand...after an elucidating chat with Bobby:
+ So Cosmo UI only refreshes with changes from the server when users
complete a view-changing user action (e.g. navigating week views,
changing collections, etc)
+ Cosmo UI only pushes changes to the server when users complete an
item-editing action (e.g. moving an event to a new date/time, saving
edits to the detail view.)
+ Conversely, when users complete an item-editing action, Cosmo UI
refreshes that item, but does NOT refresh the view/collection as a
whole (e.g. new items being created or other items having changed in
the meantime).
So, the questions are:
1. How much work would it be for Cosmo UI to refresh with changes
from the server BEFORE saving changes from the browser end?
Basically, in these rare cases, always overwriting the Cosmo users'
changes?
2. How much *more* work would it be for Cosmo UI to present the other
users changes to the user and ask them if they still want to apply
their changes?
3. How much *more* work than that would it be for Cosmo UI to be able
to figure out if there was actually an attribute-level conflict and
simply merge the non-conflicting changes.
Before go down this path though, we should wait for dogfood feedback
to try and understand how often this will happen.
Mimi
On Feb 8, 2007, at 12:16 PM, Morgen Sagen wrote:
My understanding was that if the Chandler user syncs their changes
and then pulls down conflicting changes from the server, the local
edits won't get wiped away.
A "conflict" is defined as a remote change I download when I have
local changes that I haven't yet sent (and the changes are
overlapping, and not the same value). In the case we're talking
about, the Chandler user has *already* sent their changes; the
Chandler user has no outstanding local changes that haven't been
sent to the server. Now if the Cosmo UI user overwrites the title
without seeing the change the Chandler user uploaded, and Chandler
then syncs, to Chandler there is no conflict because the Chandler
user has no local changes. There is nothing to be in conflict
with. The Cosmo UI change is applied locally to Chandler.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
