Hi Mimi, see in-line... Morgen
On Feb 14, 2007, at 2:19 PM, Mimi Yin wrote:
Hi Morgen, see in-line... Mimi
On Feb 13, 2007, at 9:42 PM, Morgen Sagen wrote:
On Feb 13, 2007, at 7:17 PM, Jeffrey Harris wrote:
I think what we want for the UI is to change lastModifiedBy (which
correspond in the UI to created by/edited by) if any changes
successfully merge in or if conflicting changes are accepted, but
not to
change lastModifiedBy if all changes are conflicting and the
conflict
either hasn't been resolved or local changes are chosen to win.
Sincerely,
Jeffrey
If I change the title of an item, the byline should now say
"edited by Me" (or something equivalent). If Joe then changes the
body on the server, and I do a background sync, what should the
byline say? There was no conflict, so following the above logic
the byline should now read "edited by Joe". Now I hit the sync
button to commit my local change and send it to the server;
lastModifiedBy is still "Joe", not "Me", so the server has the
wrong idea about who made the latest change.
I think we agreed in one of the Edit/Update meetings that we would
calculate the byline by when the last change was committed locally.
I know this has some funny consequences (e.g. Joe made a change
before me, but I don't see it until after I made my change, but the
byline still says that I made the last change.).
Perhaps we should instead think of the byline as "this item was
officially updated on the server by...", to indicate who was the
last person to change the "source of truth" for an item.
Does this work with edit/update? if I receive a change from Anita
via email Update, then I want the byline to say that the item was
Updated by Anita, not that I was the last person to sync the item
to the server?
No, it would not work in this situation. By my algorithm the server
would say that *you* had updated it, not Anita. :-(
This would mean the sharing layer would set lastModifiedBy when a
locally modified item is sent out, and it means not having the
byline change to "Me" until local changes for an item have
actually been successfully sent to the server. I think it might
be nice to see the byline change from "Joe" to "Me" only when an
item reaches the server -- it's a per-item indicator that my
changes made it out. What's also nice about this is that since
the sharing layer knows if we're *actually* sending a change to
the server (which is a function of what filters are in place and
what conflicts occur), it makes sense to have the sharing layer be
in charge of setting lastModifiedBy, just in time.
I'm wondering how often users will actually be able to 'see' these
bylines change. I think we're okay so long as users all see the
'same' byline value and we don't lose information about Updates
received via Email.
So to sum up the requirements I have here:
+ Everyone sharing sees the same byline value
+ Byline value doesn't change if there are conflicts and the
conflicting changes haven't actually been applied
Hmm, these two above requirements seem to be in conflict with each
other. I'm not sure I understand how everyone can see the same
byline if different people resolve the conflicts differently.
+ We don't lose byline information from Emails
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
