I think we finally nailed down some tough decisions tonight regarding the namespace/resource APIs...

The most important design decision is that Resource wraps an object as opposed to objects having to implement the Resource mixin. This adds a level of indirection to the APIs when working with resources, but also looks to be a simpler and more flexible design. The Resource API itself will provide the Uri for identity and will provide the CRUD methods (which will be the verbs in our REST architecture). The object wrapped by the Resource won't necessarily know or care what its Uri is or have any CRUD methods itself.

We walked thru two use cases to illustrate a both memory based resource and a ORM/SQL based resource. Main memory looks like this:

Sys.ns `/`      -> MemResource (folder)
   `/dashboard` -> MemResource -> Dashboard
   `/user/`     -> SqlTable
      `brian`   -> SqlResource -> User

In the example above the namespace root is itself MemResource with two mounted children - this is a tree data structure which lives in main memory. It is never accessed directly, but always thru Uri resolve and CRUD methods written in Java/C# which handle brief locking to make thread safe copies. The "/user/brian" resource isn't actually mapped in main memory, but lives in the SQL database and is created when resolved (caching aside).

When "/dashboard" is resolved the following occurs:

1. we lookup "dashboard" in the root object which resolves to the MemResource master copy
2. we make a safe snapshot of MemResource and Dashboard (a copy of MemResource, and a copy of Dashboard if mutable)
3. the calling threads now works with MemResource/Dashboard snapshot

When "/user/brian" is resolved the following occurs:

1. we lookup "user" in the root which resolves to the SqlTable
2. SqlTable uses its O/R mappings to resolve "brian" to a User object
3. we wrap the User with a SqlResource
4. the calling thread now works with the SqlResource/User snapshot