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?
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
+ We don't lose byline information from Emails
~morgen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
