Refactor conventional capdata body literals

[FUDCo]

At various points in the SwingSet code there are strings such as '{"@qclass":"slot","index":0}', representing the body portion of a capdata object that is being synthesized for use in some conventional role. We should factor out this string, or the pre-JSON-serialized form, into a standard constant somewhere. Or maybe into a function that takes an object reference string and returns a single-object capdata for it.

[erights]

I do not understand what this is saying. I'm not objecting. I just don't understand.

[FUDCo]

It's a magic string constant that incorporates particular details of our serialization format. It would be cleaner if it were either synthesized from actual serialization or at least named on one place so that it could be more easily updated if the serialization format changes.

[erights]

Ok sure. But with one exception, I see {"@qclass":"slot","index": appear literally only in tests.

[FUDCo]

This is not a high priority cleanup, which is why it's its own ticket.

[erights]

;)

[FUDCo]

To quote Brian Terlson, "we all have bugs we're never going to fix, that's why we file 'em".

[warner]

@erights We're transitioning away from three separate resolution API calls (fulfillToPresence, fulfillToData, reject(to data), where the first takes a single bare slot identifier (the source of your lost-interface-name problem) and the other two taking capdata. We're transitioning to a single API call resolve that takes a (list of) two-tuple of a reject boolean (false for fulfill, true for resolve and eventually forward), and capdata.

The transition is not yet complete, so there are places where we have to map from one API to the other. When the mapping receives a fulfillToPresence(slotid), it must emit a resolve(false, capdataForOnePresence(slotid)). Because this happens in the kernel or in the comms vat, where marshal is not available, and because it's so stereotypical, we're building it by hand.

It's quite possible that once we finish the transition, we won't have any occurrences of this pattern left and we won't need the refactoring.

There are two cases I can think of where the kernel needs to synthesize the result of a failed message send (messages delivered to terminated vats, and messages queued to a promise which is then resolved to a non-presence). Those might want a similar kind of refactoring, but the function would create the serialized representation of an Error object instead of a presence.

Ideally, the kernel would be completely unaware of how vats do their serialization. To accomplish this, perhaps the orphaned exports of terminated vats could be adopted by a special "error vat" which reacts to all messages by throwing an error. I'm not sure that would help with the queued-message-resolves-to-data case, though, and I'm not sure the overhead would be worth the nominal tidyness.

[erights]

two-tuple of a reject boolean (false for fulfill, true for resolve and eventually forward), and capdata.

Is this what you meant to say? In the semantics of promises, the taxonomy is

• unresolved
• resolved
  • forwarded
  • settled
    • rejected
    • fulfilled

so the leaf cases of resolved are forwarded, rejected, or fulfilled. I'll wait for clarification on this before responding to the rest.

[FUDCo]

Smallcaps renders this irrelevant. Closing.