[Cosmo-dev] Sharing format questions
Jeffrey Harris
jeffrey at osafoundation.org
Mon Jul 31 15:45:15 PDT 2006
Hi Folks,
At OSCON I had lengthy conversations with Bobby and BCM about item
uniqueness and Cosmo, I've been thinking about it since then.
Lets say there's a unique item UglyRabbit. It's conceivable that we
might move towards Cosmo insisting on users having read permissions on
UglyRabbit before they can put UglyRabbit in any other collections, if
Cosmo already knows about UglyRabbit (this is the "one soup" model).
The win here is that we can diminish network traffic in updating lots of
identical items. We can also address all items by UUID, and not have to
scope them by user or collection. I don't think (though perhaps I'm not
seeing the whole picture) that doing this avoids any merging issues, it
just makes them happen faster.
My worry is, what happens if someone revokes my original permission to
view UglyRabbit? Do I lose permission to view the item in my own
collections? That seems harsh.
I think if users couldn't rely on having access to items in their
collections it would break sharing. If you give me access to
UglyRabbit, I think I should be able to rely on having access to *that
version* of UglyRabbit in my collection on till I delete it.
At this point, it seems like we're scoping uniqueness on a per-user
basis. I think it might be easier to think about the problem if we
start by assuming each user has their own soup.
Starting there, I'd say we probably want semantics for personal
annotations that both Cosmo and Chandler's sharing code understand.
Once we had that, perhaps we'd want to add explicit Cosmo semantics for
linking an UglyRabbit in MeanHunter's soup to VeganActivist's soup,
which would only be valid as long as VeganActivist had read-only or
read-write permissions on MeanHunter's version of UglyRabbit.
Seem reasonable?
Sincerely,
Jeffrey
More information about the cosmo-dev
mailing list