On Dec 18, 2007 3:15 PM, Randy Letness <[EMAIL PROTECTED]> wrote:
> The relationship would be that they have the same uuid. One thing the
> client could do is to always assume the data in the most recently
> updated item trumps other items.
a uid is no longer a uuid if multiple items share it. every item
should have a uuid if for no other reason than that we can use that to
unambiguously locate it within a federated database.
every item could have a "copy-of" attribute that acts as a foreign
key, storing the uuid of the original item. this opens the door to
protocol queries like "find all copies of the item with uuid {uuid}".
also, this whole concept basically assumes that we want to move the
web ui to a sync model as opposed to a live query model. it's not
longer sufficient for the web ui to ask for a list of items in a
collection. it has to ask for both the member items *and* all the
items related to members that have changed since a certain time.
we could probably optimize this a bit by having the server return the
member items and descriptions of the changes to each member's copies.
the web ui could then go through a change application process similar
to the desktop's, including allowing the user to resolve conflicts.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
