Changes to @endo/pass-style and up likely needed for ocapn conformance.

[erights]

Repeating here the contents of ocapn/ocapn#5 (comment) . Please please also look at that message in context.

Taking inventory [of possible ocapn agreement] from Agoric's POV. From the thread above starting at ocapn/ocapn#5 (comment) , which is essentially that message plus the later nits raised above + the separate error thread at ocapn/ocapn#10 , I believe Agoric's current implementations are already in complete conformance with everything but the following:

• Agoric's complete absence of ByteString support feat(pass-style,marshal): ByteArray, a new binary Passable type #1538
• Agoric's incomplete and messy mapping between symbol-string-names and symbols, i.e., we do not currently accept all symbols core data types: symbol? ocapn/ocapn#46
• Agoric's errors do not make the four-way distinctions explained at How should exceptions/errors work? ocapn/ocapn#10. Everything else about errors is nebulous too. They're nebulous on purpose, but still to be worked out.
• Still not yet sure whether we miss anything we need if we omit the Promise-vs-Remotable distinction from this level. (edit: I checked this since we now have agreement to divide the Capability category into Remotable and Promise.)
• Still trying to understand precisely what we're agreeing on as the possible contents of strings. I suggest that the right criteria here is again round tripping, i.e., what are the equivalence classes that the protocol must preserve? For example, if a CESU-8 separate-surrogate encoding of well formed Unicode comes back as UTF-8, or vice versa, I think we should all consider that a successful round trip. core data types: string details, e.g. lone surrogate ocapn/ocapn#47
• -0 should round trip as distinct from 0, while still having the same rank and being keyEQ -0 should round trip through pass-style but remain equiv to 0 at patterns level #1602 WIP fix(pass-style,marshal): -0 should round trip distinct from 0 #1626

Anything else?

Taken together, these are not trivial. But these remaining issues are tiny compared to what we agree on and what Agoric already implements correctly. I suggest that this already-implemented subset is sufficiently expressive that we can start to do some real interoperability experiments immediately.

[zenhack]

Minor note of clarification, the #10 links should point to ocapn/ocapn#10; wrong repo.

[erights]

Corrected, thanks!

[erights]

At the @endo/exo level, we (Agoric) describe the interface of an exo object with an interface guard that contains a methodGuards copyRecord with one property per exo method, where the property name is the same as the method name. However, copyRecords can only have string-named properties. In order for interface guards to be able to describe symbol-named methods, we’d have to extend them with some much less natural encoding.

[erights]

#1602

[erights]

Re #1587 (comment) above

Reported at #1728

Fixed by @gibson042 at #1740

[erights]

we’d have to extend them with some much less natural encoding.

I was too pessimistic above. @gibson042 used a CopyMap, which in our system is a perfectly natural encoding. Enough so that if we had not started with a CopyRecord for the string-named methods, we might have put them all into that CopyMap. Oh well.