Formal description of serializing and deserializing a Module

[annevk]

I realize there's #956 and such, but currently I can't find any description of how Module integrates with the HTML Standard's StructuredSerialize and StructuredDeserialize algorithms and therefore how it's supposed to work with postMessage() and friends. Is this being worked on or am I not looking in the right place?

[domenic]

I hear Memory also needs to work, as a thin wrapper around a SAB.

[lukewagner]

This isn't being worked on afaik; we just have a basic description in JS.md.

[jfbastien]

It would be great to improve this. I think @mtrofin wanted to help there.

[annevk]

So I think you'll be defining your API in terms of the ECMAScript standard, not in terms of the IDL standard, right? Because if you don't define it in IDL, you'll have to effectively change the HTML Standard and define how your object is serialized and deserialized inline. (There's no extension hooks for objects defined in terms of the ECMAScript standard, only for objects defined in terms of the IDL standard.)

Either way, I'm happy to help out and I think @domenic will be too. Having a formal description might also make the security story easier to tackle.

[mtrofin]

Re. @jfbastien's comment - while I am supportive of more rigor being brought into the API spec, unfortunately I have no expertise, and therefore, no plan, to do anything there.

[jfbastien]

Assigning to @annevk.

[annevk]

So I'm happy to help with this and draft some text, but someone first needs to explain if these new objects are going to be implemented as IDL objects or something directly added to the JavaScript engine (akin to https://streams.spec.whatwg.org/) as that has implications.

[jfbastien]

What are the pros and cons of implementing as IDL objects versus direct implementation in JS engines?

[annevk]

There are some subtle differences as outlined in https://github.com/heycam/webidl/issues/226. I suspect not using IDL might also mean more work for the eventual WebAssembly translation (if these objects are also meant to be exposed there at some point)?

In general using IDL means a lot of the argument handling is taken care of by the binding, which adds some robustness, but it also comes with the subtle differences which not everyone appreciates.

Having said all that, given that you're already taking IDL-defined objects as arguments (Response for instance) you might as well go down that path I think, but it's a decision everyone needs to agree on.

[domenic]

I discussed this with @lukewagner in Berlin and we thought speccing them as IDL objects would be best, even though it's likely nobody is going to implement them using IDL bindings. (Since it's the JS engine teams at each browser working on this, and those codebases don't have access to the rest of the browser's IDL binding generation code.)

That does mean we'll need to pay special attention to the testing story since we can't take it for granted everyone will get the IDL binding pieces right. But it will avoid the continual occurrence on this issue tracker where we say "be careful not to do X, because then your API cannot be expressed in Web IDL, meaning you won't be able to do your potential future exposure to wasm plan". That seems to happen about 1/week, and would be completely obviated if we just used Web IDL anyway.

[annevk]

The alternative is that we add IDL extensions to bridge the gap. Say we have pony-interface as new alternative to interface with non-enumerable members and static methods. We'd still need testing of course, in particular for overloads, but things would also be a little easier implementation-wise and it might lead the way to more convergence between the IDL and JavaScript vocabularies.

[domenic]

I'm not sure I see the benefit of that over just using Web IDL, unless we're concerned about the compatibility implications of switching from non-enumerable to enumerable. (Which I don't think we should be, at least yet.)

[lukewagner]

And, fwiw, my reasoning is that if we can specify the wasm-to-webidl binding (as a sibling to the ECMAScript Binding, then we'd get the ability to import WebAssembly JS APIs like compile/instantiate "for free".

[annevk]

@domenic a benefit of doing it might be that we can do Streams using that and then WebAssembly gets streams "for free". And if that works out JavaScript itself could even use IDL to define objects making those also available to WebAssembly "for free".

[annevk]

Going to unassign myself since a) @flagxor has been writing patches and b) it seems someone else first needs to decide on the IDL question.