Hi,
We had a long IRC chat followed by an as long conf call today. Lots of
ground has been covered and issues mentioned that need design work. I
tried to summarized some of it here:
http://wiki.osafoundation.org/Projects/EditUpdateTracking
I left the discussion unfold and people explore various issues since it
was important for all to understand the problem in all its complex
glory. Clearly, recurring items are making this really tricky. Without
falling into a silly "let's make it simple" managerial non-sense, I'd
like to remind a couple of things though:
- We can choose to cut corners for Preview and not solve all the
possible cases. Switching back to the current "last change win" (and
data loss...) when the complexity escalate is a solution we have at hand.
- Let's try to have a workable solution for the most likely cases and
agree to be less than optimal in the rare case. e.g., a 3 way conflict
will be rare enough than asking the user to solve them sequentially
(conflict with A first, then conflict with B) is OK though inelegant
(potentially asking to resolve a conflict on the same field/attribute
twice...).
With that being said, thanks for the great discussion. Feel free to
modify the Wiki (actually, if you have tasks with dependencies on
others, you *need* to put them in the wiki...) and talk to you again
tomorrow 11am on IRC (minus PJE and Brian who won't be able to join us).
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
