SDO

Some quick notes on SDO:

IBM had this project a couple years ago where you retrieved graphs of hashtables from a system. the values of hashtables were either other hashtables or primitive types (nodes). the keys were field names (edges).

SDO looks like they took that concept, added meta-data and change logs (summaries) and coupled it to a few other specs, xpath for one.

CarrierWave was intended as an extention to an O/R or OODB tool. Maintaining typesafety, and mirroring the server side type hierarchy, were primary goals behind CW.

What I didn't see in the spec was how to define the closure of the graph. Additionally, SDO does not support faulting of objects into the local process space.

CW does both. You can specify a GraphPlan by depth (and other meta data) or define it explicitly via GraphNode trees (node trees are used internally for all traversals). Or you can add a hook that faults in objects as you walk the graph (object.getSomeChildObject().getSomeOtherObject()).

CW does have a fair amount of meta-data associated with every type. Enough to manage the whole object graph in a typeless fashion. field names, field types, contained types, read-only, literal (primitive) or object, etc.

Another thing I did not catch in the SDO spec was identity. No dependent or independent types. CW uses a single token object (an Icon, think IOR) to represent the identity of the local client side object and the server side object. some objects have identity, some (dependent) objects are only identified by their relationship to a parent identifiable type.

So with an Icon, you can identify the root of a graph, and with a GraphPlan, you identify the closure of the graph.

What is interesting is the ChangeSummary. that could be a way to improve some aspects of the performance in CW. Something to look into.

[updated]

I should add that CW does track when an object becomes dirty, and only dirty objects are modifed on the server. It's left to the client to filter out 'clean' objects to save bandwidth (if necessary). The ChangeSummary seems to be much more fine-grained.