At 03:36 PM 2/14/2007 -0800, Jeffrey Harris wrote:
Hi Phillip,
> That sounds good, except that it's not really defined. In the
> edit/update case, I could email you a change Morgen made, along with a
> change that I made previously (but Morgen's change is later, so my
> lastModifiedBy says Morgen).
>
> Now, if one or both changes conflict with your Chandler, then what do we
> do to your lastModifiedBy? Under the model you propose, it is quite
> possible to have a situation where, no matter what we do, the value will
> be wrong!
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.
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."
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
