On Feb 14, 2007, at 4:45 PM, Mimi Yin wrote:
On Feb 14, 2007, at 4:16 PM, Phillip J. Eby wrote:
I don't follow why the value is wrong here. The lastModifiedBy
from the
email would be Morgen, because his change was later. If any changes
don't conflict, the item changes to say Morgen changed it last.
If the conflicting change was by Morgen, then it will say Morgen
changed it... when his changes haven't actually been applied.
If it's okay to do this, then it should be equally okay to say
Morgen changed it, *regardless* of whether there were any
conflicting changes.
I think I'm still lost on this part...
It's true that a particular change you made may look like it was
made by
Morgen, but I think Mimi's saying that's an acceptable failure
mode for
preview, so it's not wrong.
Right, but by the same logic, the case where we simply always
update lastModifiedBy is never any *more* "wrong" than this... but
is much simpler to implement and is easier to explain.
That is, the rule is simply "Morgen changed the item last," not,
"This is who changed it last unless there's a pending conflict, in
which case it might or might not be the person who changed it last."
In my mind, the difference is between:
Getting the byline wrong between 2 users who both had changes
applied to an item; VERSUS
Getting the byline wrong between 2 users, one of whom never had
their changes applied.
I don't know that the rule is as simple as 'Morgen changed the item
last'. Which item? Morgen may have been the last person to change a
version of the item (Morgen's version). But Morgen's change wasn't
applied to my version of the item. It's more like, the last
attempted change on the item. I think both rules are equally hard
to explain because what makes it weird are idiosyncrasies having to
do with sync.
All things being equal, I would go with the former. However, if
we're wrestling with the implementation, it's not a hard and fast
requirement, just a design preference. In other words, we don't
need to block on this for Preview. We should log it as something we
should address post-Preview.
Mimi
Here is my take on what's realistic for Preview:
Whenever the user makes a change to an item in the detail view or the
week view, the lastModifiedBy attribute for that item gets set to
'My' email address *** and the lastModified (time) attribute gets set
to "now". This updates the byline in the detail view to say "Edited
by me on ...".
If a change comes in via edit/update email or via server sharing, the
update will contain a lastModifedBy email address and a
lastModifiedTime. Regardless of whether any changes from that update
are actually applied (because of filtering or conflict), the byline
will update to show the new lastModifiedBy and lastModified (time) --
but only if the incoming lastModified (time) is more recent than the
item's current lastModified (time).
This means that if A sends a change to B, and B makes no changes but
forwards that change to C, C will see that the change was made by A.
If A sends a change to B, and B has also made a change, whoever made
the change more recently will be in the byline.
Jeffrey and I discussed a way to perhaps skip the setting of
lastModifiedBy if none of the other changes are applied, but this
would need to be post-Preview.
*** 'My' email address: have we determined which of the possible
several email address to use? And what if the user hasn't entered one?
~morgen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
