Mojo IPC instead of Proto?

[justinfagnani]

Disclaimer, I don't work on Chrome proper, so claims here may be overstated a bit :)

Chromium has separated many features in to services that communicate via Mojo IPC.

Some possible advantages of using Mojo IPC over Protos, that I'm extracting from a pretty cursory reads of docs:

• It may be possible to utilize Chromium's set of services to provide network, filesystem, storage, audio, etc., APIs. I'm not sure indexeddb is a service yet, but if it is, then you could offer first-class indexeddb support furthing the web-compatible story.
• It would provide a native extension point that's compatible with Chromium's internals, and automatically callable from JS.
• Mojo historically at least is designed to support multiple language runtimes, V8 being just one. Maybe deno could support other runtimes like Python, that have access to the same Mojo Services, whether provided by native code, or from JavaScript.

I think a sandboxed, multi-language runtime based around Chrome's IPC system is would be very, very interesting.

[kenchris]

Mojo is also used by Flutter (or at least was used extensively back when it was called Sky, but I wouæd assume that didn't change)

[kenchris]

https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md

[kenchris]

Good list of things being modulized inside blink via Mojo:

https://chromium.googlesource.com/chromium/blink/+/master/Source/modules/

[ry]

Interesting - I didn't know about Mojo.
I won't do this (now) because

• the project is very bug and non-functional and the serialization layer isn't part of that bugginess
• the reasons they list to use Mojo instead of protobufs is to "support transfer of native object handles (e.g. file descriptors) across process boundaries." This is not a feature deno would need - the IPC is just for communication in the same process between V8 and Go. Even if they were different processes, V8 is supposed to be a complete sandbox in Deno and not make syscalls itself. So there's would be no need to send it (functional) file descriptors.
• Deno is trying to be minimal and thus I'm afraid of diving headfirst into Chrome infrastructure - because it can get interdependent and large quickly.

but thanks for the links - it's good to know about.

[justinfagnani]

@ry thanks for looking into it! I think the benefits from this project using Mojo would be around the web compatibility goals. Offering web APIs like Bluetooth, NFC, WebAudio, fetch(), etc., might be easier if you could just use the Chromium implementations. Maybe worth thinking about again in the future.