If the 'same item' on the server has different UUIDs, is this going to affect edit/update scenarios on the desktop? Edit/Update allows users to essentially share an item via email. But it only works if the item being sent back and forth has the same UUID at both ends.

What happens when the 'same item' *is* actually added to a shared collection? Will you end up with 2 versions of that item in the collection? We'd have to something to make sure they 'rationalize' to become the same item.

Mimi

On Dec 18, 2007, at 4:02 PM, Brian Moseley wrote:

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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to