sharedState

The sharing spec requires we be able to determine which items are:

• unshared
• read-write
• read-only

All but one of the scenarios described in the sharing spec can be implemented by:

• Adding a sharedState attribute to ContentItem whose values are the 3 listed above; the initialValue is "unshared"
• Upon publishing a collection, all items in that collection will locally have their sharedState set to "read-write"
• Upon syncing a read-only collection, all imported (new and existing) will have their sharedState set to "read-only" unless it is already "read-write"
• Upon syncing a read-write collection, all imported items (new and existing) will have their sharedState set to "read-write" unless already set
• Upon syncing any collection, if an item was removed (either locally or remotely) we have to see if that item belongs to any other shares we have and set sharedState to the "highest" appropriate ACL. In other words:
  • unshared -- if the item doesn't belong to any other shares
  • read-only -- if the item appears only in read-only shares
  • read-write -- if the item appears in any read-write shares

(Alternatively, rather than having the sharing code set the sharedState attribute, ContentItem could just have a method which determine the sharedState value as needed. I'll try the method first to see if it's fast enough)

The complication comes from this scenario in the spec:

If a user receives an item via a read-only share, they can add it to any of their other collections (shared or not shared). If they add the read-only item to another collection which they are sharing read-write, the item maintains it's read-only-ness. Therefore neither the user nor any of the sharees of the read-write collection have read-write priveleges on that single read-only item. Example: Blue subscribes to the 543 Howard Street building maintenance calendar with a read-only URL. She notices that next Thursday, the building maintenance folks are going to drill a big hole between the 4th and 5th floors to make way for a huge waterslide. She decides to add this event to the KEI Office calendar, which she shares with everyone, read-write. The "Drill big hole between 4th and 5th floors" event remains read-only for Blue and all KEI sharees, even though the KEI office calendar is being shared read-write.

This requires that some additional information be carried along with the read-only item; the problem is that the sharedState isn't really an inherent attribute of an item, but more a function of how a sharee received the item; for that reason we won't be including the sharedState value during sharing -- what's read-write for one person isn't necessarily so for another.

Further thought will have to go into the "unchangeable item in a writeable share" problem. Server-side per-resource ACLs may be required.

It could be argued that if an item gets added to a writeable collection, that anyone with write access to that collection should be able to modify that item; because of server-enforced permissions (on entire shared collections), nobody will be allowed to write that item to a collection they don't have write access to. Perhaps for 0.6 that is okay?

For 0.6 we're going to let the read-only item get converted to read-write, then readdress this issue for 0.7

Determining which shares an item particpates in

Above I mentioned that we will need to be able to quickly determine what shares an item participates in. For the near future, it should be sufficient to ask the item what ItemCollections it belongs to (assuming we can do that), and then iterate those, examining the Shares each ItemCollection is associated with. If it is not possible to go from item to ItemCollection, I'll have to add my own references between share and item.