[cosmo-dev] a new year, same problem

Brian Moseley bcm at osafoundation.org
Fri Jan 4 12:41:51 PST 2008

On Jan 4, 2008 12:22 PM, Travis Vachon <travis at osafoundation.org> wrote:

> 1) Include links to all "copies" of an item in its representation.
> 2) Include links to "conflicts" in the representation of an item that
> has been updated in one collection but not another.
> 3) Provide a link to resource that would help sort this out, which
> would be requested when an item is selected in the web ui.

how about 4) Provide a description of each conflict in the item's
entry? Maybe in a collection's feed we provide enough information for
the UI to show an icon for each item indicating that it has conflicts
to process, and in an item's entry we actually provide all of the
conflict details. that way the client can, when filling in the DV,
resolve the conflicts and apply changes back to the item on the server
(or present a conflict resolution UI to the user, or whatever).

FeedSync (used to be SSE) is an Atom extension that provides conflict
resolution capabilities. I haven't gone over them in detail in quite a
while, so I'm not sure if Feedsync maps well to our problem, but it's
something to look into.

> Similarly, updating an item in multiple collections at once is
> infeasible because, with the exception of some overlay related ui
> state scenarios, the client has no way of knowing which collections an
> item belongs to. Solution (1) above would help solve this.

you probably don't want to update any copy of the item other than the
one in the collection you're viewing. rather, you want conflicts to be
resolved in each collection when it "comes into focus". otherwise, how
do you give the user any way to participate in the resolution process?

if all we want is some sort of "last write wins" policy, i guess we
could update all copies at once. the client doesn't need to know about
all the copies - it just needs to tell the server to propagate the
change to all copies, and the server can handle that itself. but that
introduces the problem of locking multiple collections on a single
update, which I think we'd pefer to stay away from.

> Not sure I follow.. assuming the desktop client hasn't synced things
> up, which of the various copies of an item would this return?

each instance of an item has a uuid (universally unique) and a cuid
(unique within a collection). therefore, /item/{uuid} addresses one
and only one instance of an item in the universe. to address by cuid,
you need to also provide the uuid of the collection in which that cuid
is scoped.

More information about the cosmo-dev mailing list