IDL?

[zenhack]

There's been some discussion re: whether ocapn should include an IDL, and if so where it should exist in the stack. I sense a general agreement that we want the protocol messages to be "self describing," and @cwebber has suggested that an IDL, if it exists, ought to be a layer on top of this.

There's broader discussion to be had about this; this issue can be its home.

[kriskowal]

In the scope of interoperability between Agoric and Spritely, we have elected to not address the concern of an IDL at this time and all proposals have focused on a self-describing protocol.

I move that we can close this issue either with agreement between editors @tsyesika or bring this up to hopefully close at a future meeting @jar398

[kriskowal]

I will note some nuances however:

• Agoric uses a pattern language that can be described in terms of the OCapN data model for describing protocols above OCapN, e.g., signatures of OCapN functions. This is spiritually similar to an IDL, but does not constrain the interfaces of remote capabilities in the way an IDL would. I would invite @erights to expand on why.
• There certainly could be an IDL to describe constraints on protocols above OCapN and that IDL could be used for runtime validation of the tentative Syrup based concrete wire protocol, or to generate a validator.
• That IDL could conceivably be used to generate other wire protocols or translators between the OCapN Syrup wire protocol and other wire protocols, or even generate other IDLs and wire protocol translators for those IDL based protocols.

I take these freedoms as evidence we can proceed with an IDL-free protocol and still have options to introduce IDL later.