endojs
Changes to @endo/pass-style and up likely needed for ocapn conformance.
Repeating here the contents of https://github.com/ocapn/ocapn/issues/5#issuecomment-1550492042 . 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 https://github.com/ocapn/ocapn/issues/5#issuecomment-1549012122 , which is essentially that message plus the later nits raised above + the separate error thread at https://github.com/ocapn/ocapn/issues/10 , I believe Agoric's current implementations are already in complete conformance with everything but the following:
- [ ] Agoric's complete absence of ByteString support https://github.com/endojs/endo/pull/1538
- [ ] Agoric's incomplete and messy mapping between symbol-string-names and symbols, i.e., we do not currently accept all symbols https://github.com/ocapn/ocapn/issues/46
- [ ] Agoric's errors do not make the four-way distinctions explained at https://github.com/ocapn/ocapn/issues/10. Everything else about errors is nebulous too. They're nebulous on purpose, but still to be worked out.
- [x] 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. https://github.com/ocapn/ocapn/issues/47
- [ ] -0 should round trip as distinct from 0, while still having the same rank and being keyEQ https://github.com/endojs/endo/issues/1602 https://github.com/endojs/endo/pull/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.
Minor note of clarification, the #10 links should point to https://github.com/ocapn/ocapn/issues/10; wrong repo.
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.
Re https://github.com/endojs/endo/issues/1587#issuecomment-1579723407 above
Reported at https://github.com/endojs/endo/issues/1728
Fixed by @gibson042 at https://github.com/endojs/endo/pull/1740
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.