For the kernel, dump() returns a JSON-serializable object graph (so each Map is iterated and converted into an object, and some of the redundant tables are merged). The idea is that the Controller can make this safe for inspection by doing a JSON.parse(JSON.stringify(kernel.dump())), sort of "laundering" it through a string, so that we wind up with something that 1: consists only of objects from the outer Realm, and 2: can't be used to mutate the kernel tables.
I see the comms layer has some dump() methods, but it looks like sometimes they return strings (like in makeAllocateID.js which returns a stringified integer), and sometimes they return Maps (like in makeCLists.js).
We should probably unify these, so we can rely upon the behavior. For debugging and for tests, I've found it pretty handy to produce a JSON-able object graph, We may want that for vat/kernel save/restore too, since we need something that can be hashed and fed into the consensus mechanism. So maybe we should arrange for the top-level dump() to return something that can be fed into JSON.stringify(), and then all the internal dump() methods can do whatever they like as long as it meets that goal (e.g. makeAllocateID could return the plain integer, makeCLists would have to return an object or an array, etc).
For the kernel, dump() returns a JSON-serializable object graph (so each
Map
is iterated and converted into an object, and some of the redundant tables are merged). The idea is that the Controller can make this safe for inspection by doing aJSON.parse(JSON.stringify(kernel.dump()))
, sort of "laundering" it through a string, so that we wind up with something that 1: consists only of objects from the outer Realm, and 2: can't be used to mutate the kernel tables.I see the comms layer has some
dump()
methods, but it looks like sometimes they return strings (like inmakeAllocateID.js
which returns a stringified integer), and sometimes they return Maps (like inmakeCLists.js
).We should probably unify these, so we can rely upon the behavior. For debugging and for tests, I've found it pretty handy to produce a JSON-able object graph, We may want that for vat/kernel save/restore too, since we need something that can be hashed and fed into the consensus mechanism. So maybe we should arrange for the top-level
dump()
to return something that can be fed intoJSON.stringify()
, and then all the internaldump()
methods can do whatever they like as long as it meets that goal (e.g.makeAllocateID
could return the plain integer,makeCLists
would have to return an object or an array, etc).