[cosmo-dev] a new year, same problem

[Travis Vachon]

I've hesitated to respond until I could get my brain wrapped around  
this thing. I'm still a little fuzzy, so forgive me if some of this is  
less than totally thought out..

At the moment I'm pessimistic about the proposal to do conflict  
management in the web ui. From http://chandlerproject.org/Journal/CosmoC18NNotes 
:


     *  Brian updates "weekly meeting" in "work" by changing the  
duration
     * Randy updates "weekly meeting" in "my stuff" by changing the  
body to "losers"

The copies of "weekly meeting" are now out of sync.


When Bobby uses the web ui to look at his collections, he'll first  
look at "work" and see Brian's changes. At this point there is no way  
for the web ui to know that a different change has been made in "my  
stuff," since the data in that collection hasn't even been requested  
from the server. A few possible solutions:

1) Include links to all "copies" of an item in its representation. The  
web UI would then be responsible for making an http request to each  
and making sure there are no changes. We might even be able to  
optimize this using etags or something similar.

2) Include links to "conflicts" in the representation of an item that  
has been updated in one collection but not another. This would require  
the server to do some amount of automatic updating of items during  
modifications and grok conflicts. I'm not actually sure this would  
look much different than (1), except for being more complicated.

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. This  
resource might be a list of copies of an item, a representation of  
copies of an item that are different than the current item, or  
something else entirely (??)


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.


All that said, I don't like the idea of leaving the desktop client as  
the only party responsible for syncing copies of items, as it  
basically takes away server support for relationships between copies  
of an item (except for the fact that we'd keep uuids that would be  
shared by all copies of an item, if we do that). It seems to me that  
entirely stand-alone users in this world would essentially never see  
the relationship between copies of an item.

> the following URLs might all
> address the same item:
>
>   o /atom/item/{uuid}

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

I'll let this keep rolling around in my head and update here if I  
think of anything (hopefully slightly more constructive ;-)

-Travis

On Jan 4, 2008, at 11:09 AM, Brian Moseley wrote:

> On Jan 2, 2008 9:44 AM, Randy Letness <randy at osafoundation.org> wrote:
>> I thought maybe a the new year would result in the "items in multiple
>> collections" problem disappearing, and well I guess it didn't happen.
>> So back to reality.  I've started another wiki page on the idea of
>> "compartmentalization", that is, representing items in multiple
>> collections as copies of the item in each collection:
>>
>> http://chandlerproject.org/Journal/CosmoC18NNotes
>
> I'm generally in favor of this, as long as we can agree on an approach
> for the web UI conflict problem. I'd like to hear what the UI guys
> think about the idea.
>
> assorted thoughts:
>
> * how about calling it "collection-scoped uid" or "cuid" rather than
> "client uid"? it won't always be assigned by or known to the client
> (for example, CalDAV clients and GreaseDoggy)
>
> * this lets us go back to more descriptive/meaningful/"cool" URLs,
> which I know lots of people would like. the following URLs might all
> address the same item:
>
>   o /atom/item/{uuid}
>   o /atom/{user}/collection/{collection uuid}/cuid/{cuid}
>   o /atom/{user}/collection/{collection uuid}/name/{sanitized  
> display name}
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev