dckc
commented
1 year ago recent discussion, to wit:
Dec 06 15:12:21 <KrisKowal[m]> <dckc> "how does one conduct testing for..." <- Indeed, the test suite should be framed in terms of interaction among ocapns, and to test interop, captps would need to adapt to ocapn as writ on the wire.
Dec 06 15:13:11 <KrisKowal[m]> presumably guile and racket would speak to the tests directly, but agoric’s captp and cap’n’proto would need a proxy.
Dec 06 15:14:41 <KrisKowal[m]> with tests of sufficiently fine granularity, it will be nice to see the first green row and work out from there. will be interesting whether that first row involves records of lambdas / or objects of methods!
Dec 06 15:16:57 <cwebber> I think having the test suite that has one concrete syntax and building adapters makes sense
Dec 06 15:17:17 <cwebber> at any rate, the grant promised a test suite that started with the stuff we have in spritely and iterates with the group's input
Dec 06 15:17:37 <cwebber> so the adapter layer is a really clever idea
Dec 06 15:18:56 <isd> My sense here is our goal is to specify a single protocol with concrete encoding, But we would design this with an eye towards being able to bridge it to the existing protocols that can't change to satisfy it (and we'd actually build these bridges). So the test suite is for the protocol we're designing, and the bridges should use said test suite. But we're not going to build a test suite where the concrete serialization is pluggable or anything like
Dec 06 15:18:56 <isd> htat.
Dec 06 15:19:36 <cwebber> I think shipping actual bridges would be a wonderful output of the group anyway
Dec 06 15:19:44 <cwebber> after all, captp is just a membrane
Dec 06 15:20:06 <cwebber> and there can be multiple membranes
Dec 06 15:20:14 <cwebber> but translator between membranes,
Dec 06 15:20:16 <cwebber> that's an interesting idea
Dec 06 15:24:36 <dckc> this all sounds wonderfully concrete to me :)cc @kriskowal @cwebber @zenhack -- should I move this to https://github.com/ocapn/ocapn/issues ?
analagous to decodeToJustin, decodeToCapn might provide the sort of bridge in our recent discussion.