Implement serializable and transferrable web platform APIs

[andreubotella]

Deno's implementation of structured serialize currently supports serializing the JS built-in SharedArrayBuffer, and transferring the JS built-in ArrayBuffer as well as the MessagePort web API. With #11823 it will also support serializing the wasm built-in WebAssembly.Module.

But Deno also implements some web APIs that per the spec should be serializable or transferable but aren't in Deno's implementation. In particular, DOMException, File, Blob and CryptoKey should be serializable; and ReadableStream, WritableStream and TransformStream should be transferable.

Implementing this would probably need adding some Deno.core API to define serialization and transfer steps, possibly in connection to the existing Deno.core.createHostObject(). This would also allow refactoring the implementation of MessagePort.

[kitsonk]

I don't know if we would need to have have extensions to Deno.core. Wouldn't we just need something like:

const denoSerialize = Symbol("Deno.serialize");
const denoDeserialize = Symbol("Deno.deserialize");

class DOMException {
  static [denoSeralize](instance) {
    // serialize steps that return a v8 serialization
  }
  static [denoDeseralize](value) {
    // returns a hydrated instance from a v8 serialization
  }
}

And if we put the denoSerialize and denoDeserialize in the web platform helpers and not using .for() would ensure they are unique and not accessible from userspace.

[andreubotella]

I don't know if we would need to have have extensions to Deno.core. Wouldn't we just need something like:

const denoSerialize = Symbol("Deno.serialize");
const denoDeserialize = Symbol("Deno.deserialize");

class DOMException {
  static [denoSeralize](instance) {
    // serialize steps that return a v8 serialization
  }
  static [denoDeseralize](value) {
    // returns a hydrated instance from a v8 serialization
  }
}

And if we put the denoSerialize and denoDeserialize in the web platform helpers and not using .for() would ensure they are unique and not accessible from userspace.

That wouldn't be enough, at least for serializable interfaces, because the serializable platform objects might be deep into the object graph. Deno.core.createHostObject() is the only current way to implement custom serialization – with v8::ValueSerializerImpl::write_host_object() (although see https://bugs.chromium.org/p/v8/issues/detail?id=11927 for adding an easier way to fix this in v8).

---

Edit: Rereading the post above, I see that maybe @kitsonk meant adding custom symbols in addition to creating the object with Deno.core.createHostObject(). And yeah, that might work.

[kitsonk]

Edit: Rereading the post above, I see that maybe @kitsonk meant adding custom symbols in addition to creating the object with Deno.core.createHostObject(). And yeah, that might work.

I hadn't but I understand the point better about write_host_object() that I hadn't appreciated.

[rracariu]

Curious if deep freeze objects can be safely considered as Transferrable, and if not, what would be the limitation for that?

[andreubotella]

Curious if deep freeze objects can be safely considered as Transferrable, and if not, what would be the limitation for that?

User-created objects, whether frozen or not, are automatically serializable (not transferable, which in this context means that the original object is no longer usable after you transfer it, as happens with MessagePort), but the resulting clone won't be frozen. And as usual with the structured clone algorithm, the prototype won't be preserved. This isn't something we would want to change, since that's how browsers do things.

But this issue is about the web APIs that Deno implements, and how their behavior with the structured clone algorithm doesn't match browsers. For these APIs, browsers do preserve their prototype, as well as associated state – and Deno should do the same.

[andreubotella]

So one of the problems with the symbols that @kitsonk suggested is that we need to be able to find the right class when deserializing an object – if you create a subclass of, say, File, and then serialize it, the deserialization must call File[denoDeserialize](), not FileSubclass[denoDeserialize](). And this must happen even if the user has deleted globalThis.File.

[kitsonk]

A map registry of transferabld prototypes? The only problem with that is they wouldn't have access to private fields, though I believe we don't use them for web platform prototypes, but instead use symbols again.

[andreubotella]

Since registering an interface as serializable or transferable is going to be needed either way, why not register it together with (de)serialization functions?

Deno.core.registerPlatformInterface({
  name: "Blob",
  serialize(instance) {
    // TODO
  },
  deserialize(value) {
    // TODO
  },
  // Transferable interfaces would have the `transfer` and `transferRecv` functions.
});

and Deno.core.createHostObject() could be changed to take the interface's name, which it'd store as the object's embedder field.

Doing the serialization based on an object's prototype hierarchy would lead to fakeBlob below serializing as a Blob, which shouldn't happen per the spec:

const fakeBlob = {};
Object.setPrototypeOf(fakeBlob, Blob.prototype);
Deno.core.serialize(fakeBlob);