r6 - 06 Feb 2008 - 07:13:42 - RandyLetnessYou are here: OSAF >  Journal Web  >  ContributorNotes > RandyLetnessNotes > CosmoAccessControlNotes > CosmoC18NNotes

C18N

C18N is a term coined by Morgen, and stands for "compartmentalization", which refers to the idea of an item's uuid being unique within a collection, and not system wide like it is today. The idea is that this will solve a lot of access control problems we have today, along with providing many other benefits including:

  • Removes the need for complicated logic on the server to handle keeping recurring events and modifications in sync multiple collections (getting rid of this logic simplifies server logic greatly)
  • Makes data partitioning easier as all data can be grouped by collection, and all collections can be grouped by user
  • Solves problem of having to deal with adding an item addressed by /dav/user/collecitonA/itemA to collectionB where collectionB already has an item addressed by /dav/user/collectionB/itemA (cosmo currently doesn't handle this and pretends it doesn't happen)
  • Other Chandler benefits like being able to use the icalUid to map to uuid, being able to share different sets of attributes on a per user basis, and being able to support the peer-to-peer sharing model (User 1 shares to User 2, and User 2 shares to User 3. Users 3's changes only get to User 1 through User 2)
  • With c18n, If someone gets a hold of one of your item's uuid (through email or some other means), they can't modify your copy of it unless they also have write access to a collection that you are syncing. And if they do try to slip a change through some other collection you're syncing, Chandler's conflict management will flag it as a pending change for you to approve/decline.
  • Today, without c18n, if someone has one of your uuids, they could publish it to the server before you get a chance to, thereby preventing you from publishing your own item!
  • With c18n we could provide users with a way to replicate their collections among their own multiple clients, keeping "read/unread" in sync, etc. By publishing a second copy of a collection to the hub, Chandler could include all the "private" attributes that you wouldn't want to share with others, but which you do want to share with yourself across multiple Chandlers.
  • Without c18n we moved away from deterministically generating an item's UUID from its icalUID, because when multiple users import a public .ics file from somewhere and then publish the calendar to the Hub we want the items to be distinct. I believe this is leading to having multiple UUIDs with the same icalUID as Jared is seeing on the Hub. With c18n, we can go back to generating UUIDs based on icalUID, solving this problem, while still allowing people to publish the same .ics-imported public calendar to the Hub.

It should be noted that before the move to morse code, Chandler published each collection as a separate dav collection, which resulted in c18n. Chandler continues to work this way, with the difference being instead of dav, morse code is used.

With C18N, an item in multiple collections is represented as multiple copies of the item, with one copy stored per collection. A collection then becomes a "view" of that item, meaning that the item copies may not be in sync. Consider the following (assuming everyone is using Chandler) :

  1. Brian creates a collection "work" with item "weekly meeting"
  2. Brian shares "work" read-write
  3. Bobby subscribes to "work", adds "weekly meeting" to his personal collection "my stuff"
  4. Bobby publishes "my stuff" and shares it read-write
  5. Randy subscribes to "my stuff"

On the server, this would be represented as two collections, "work" and "my stuff". Each collection would have a copy of the "weekly meeting" item, related because they have the same uuid assigned by Chandler. This allows Randy to update the copy of "weekly meeting" in "my stuff" without touching the copy in "work". Then Bobby can choose to update the copy of of "weekly meeting" in "work" because he has write access. Access control solved.

WebUI? concerns

Because Chandler maintains its own item repository and has conflict resolution, it is able to merge the different copies into a single item displayed to the user. The webui has no repository or conflict management, so how can it manage copies of the same item? For instance:

  • 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. The next time Bobby syncs, he gets the changes from Brian and Randy, and using Chandler's conflict management, decides which changes to apply, resulting in the items being in sync again.

If Bobby uses the webui instead of Chandler, he will see different data depending on which collection he is viewing. Possible solutions:

  1. Rely on Chandler to sync the items for now. Display the data according to the currently selected collection. If an item exists in multiple collections and those collections are overlayed, display the data from the selected collection. This may result in the item's data changing depending on the current collection. This makes sense if you believe that the webui is primarily used by the casual collaborator and that all complex usage (items in multiple collections/conflict resolution/etc) is left to Chandler users. this might be a good short term solution.
  2. Provide conflict management in the webui to resolve out-of-sync copies. I think longterm we want to provide a way for the webui to detect out-of-sync items and provide a way to merge and resolve conflicts. ??

The same problem exists for updating an item existing in multiple collections. Chandler issues multiple update requests when an item that exists in multiple collections is updated. The webui currently uses a single request. Possible solutions:

  1. Rely on Chandler to sync the items for now. Continue to issue a single request, which would update the item in a single collection. Updates to other collections would be handled by subsequent Chandler syncs.
  2. Provide support in protocol for updating multiple collections in a single request. If an item exists in multiple collections, provide support on the server for updating each copy in a single request. This gets complicated when an item exists in collections that the user doesn't have access to. For example in the above case, when Randy updates "weekly meeting", he only has access to "my stuff" so the copy in "work" shouldn't be updated.

Other concerns

Another scenario that may need some thought:

  1. Brian creates a collection "work" with item "weekly meeting"
  2. Brian shares "work" read-only
  3. Bobby subscribes to "work", gets all items read-only
  4. Bobby unsubscribes from "work", re-publishes all the items in his own collection "my stuff" read-only. This results in the items having the same uuids as the "work" collection items. Bobby can update these new items because he owns them, but he doesn't have write access to Brian's "work" collection, so he can't modify those items.
  5. Randy subscribes to "work" and "my stuff"

Randy is now subscribed to "work" read-write and "my stuff" read-only. Items in these collections have the same uuids, but these items should no longer be related to each other. Chandler handles these duplicate uuids as a single item and will merge all changes into a single item, when there should really be two different views of the item (one for Bobby's version and one for Brian's version).

Server Changes

Schema Changes

  • Move back to an item having a single parent
  • Add clientUuid property (the uuid assigned by the client) which represents the uuid that should be unique within the collection. There will still be a uuid property, which will be assigned and used on the server only, and will be unique across all items.
  • Add support for an additional identifier for collections so that a collection with the same client uuid can be published multiple times. (we can use the existing "name" property, or the server uuid).

Protocol Changes

  • None for now, the only change is that the uuid in the uri refers to the server-assinged uuid and not the uuid assigned by the client, but this shouldn't affect the client at all

Service Changes

  • None for now, although in the future we probably need the ability to look an item up by collection/client-assigned uuid and the ability to update multiple related items

Migration

  • existing uids become clientUuids, new uuids assigned for server use
  • create copies of all items that are in multiple collections

Chandler Changes

None for now. If we want to support being able to publish the same collection multiple times, then Chandler would have to handle storing an additional key in addition to the collection uuid and be able to deal with the multiple collection shares.

Webui Changes

Need some help here, but I'll take a stab at it.
  • Handle items in multiple collections when those multiple collections are overlayed
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r6 < r5 < r4 < r3 < r2 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.