add description to pass-by-presence objects?

[warner]

For debugging (as well as general learn-by-experimentation), it would be nice to have a way to attach descriptions to the various pass-by-presence objects we fling around. The current situation is that these arrive as a Presence on the remote side, which is an empty harden()ed object with nothing to suggest what it's good for, where it came from, or what methods it might respond to.

The simplest improvement would to just make sure that .toString() can be (remotely) invoked, and establish a convention of including a toString() when you construct the object. This requires a roundtrip to do the lookup, and doesn't reveal any information to the kernel, so it's only usable from some other vat.

Another approach that we kicked around today would be to define a special symbol (a "registered Symbol", in JS parlance) that we use to attach a descriptive string. The construction-time syntax would look like:

const DESC = Symbol.for("description");
const p = harden({
  foo(args) { doStuff(); },
  [DESC]: 'I am a Foo that can do foo(args)',
});

The description string is the magic one: it would match something defined in liveSlots.js so the marshalling code can recognize the property. We could also pass the symbol into userspace the same we pass E.

To implement this, we'd need to change:

• marshal.js: the presence of this Symbol shouldn't disqualify the object from pass-by-presence serialization
• liveSlots.js: define the symbol, serialize pass-by-presence with an additional property (instead of just { type: 'export', id }, it needs to be { type: 'export', id, description })
• the syscall.send and dispatch.deliver protocol must change to include the description on the first delivery of the presence record
• vatManager.js needs to track exported presence records (which it doesn't currently track), to make sure we capture the description only on the first time the presence is exported from a vat. We need these to be immutable, and if a non-liveslots userspace decides to change the description each time it exports the same object, the kernel and other vats shouldn't see the changes.
• kernel.js and the dump() function would benefit from including these descriptions in the printable representations of the kernel c-list tables

[erights]

See #804

[erights]

As an aid to debugging under benign conditions, done. Closing.