Webmapper and Web Assembly

[Travis West]

Some food for thought. TL;DR: maybe we should refactor webmapper to use webassembly. It would be tricky, but probably worth it?

Should Webmapper be refactored to use the libmapper library directly, via emscripten/web assembly?

 - I would argue that this would be a major step forward for the ecosystem. Right now webmapper is one of the most central and complex applications that use the library, but most of webmapper's functionality is implemented in the browser on top of its own javascript-based re-implementation of a lot of the functionality provided by the C library. I think moving Webmapper towards using the C-library directly would ultimately end up pushing the library in ways that would improve its overall usability and usefulness. There are also a lot of features that would be very useful for webmapper to have, but which are presently difficult to implement because of the libmapper->python->websocket->javascript architecture in which the webmapper UI (in the browser) is not a direct participant in the libmapper network. It's hard to make things like signal monitors or sliders that set destination endpoint values, because you end up having to implement a lot of plumbing between the browser and the server.

If one were to try to make this change, what would be some of the main technical hurdles?

 - In brief: you have to compile the library for the browser, you have to modify the library to work around the limitations of the browser (especially the absence of true UDP, no multicast bus, no direct communication with other UDP endpoints), and you have to refactor webmapper to use the library directly.

What's hard about compiling for the browser?

 - Libmapper itself only has one external dependency, namely liblo, and it doesn't directly make use of a great deal of posix functionality that might not be available in the browser. To compile the library for running in the browser, you "just" need to compile liblo and then libmapper for the browser.

 - Unfortunately, liblo has a few dependencies that are not readily supported by emscripten (at least when I tried to do this a few months ago). Notably I had trouble with compiling gzip to wasm, even though only the CRC functionality of gzip is used.

What's hard about the lack of UDP?

- Either you need to extend liblo to support browser-oriented networking, like websockets or webRTC, or you need to extend libmapper in the same way. You also need to extend one of these libraries to support network topologies without a shared administrative bus; the obvious approach, to me at least, would be to allow a configuration where a device that is unable to access the bus (e.g. the browser running Webmapper) is instead allowed to connect to any other single device that is connected to the bus, and then have that bus-connected device forward all bus communication from the bus to the browser, and from the browser to the bus, acting as a bridge between the browser and the bus. For that to work, you need some way for the browser to discover other devices without access to the bus; an acceptable stop-gap might be for the python webmapper server to continue to exist for the purpose of acting in this bridging capacity, with the port and IP of the server dynamically set server-side so that the browser client can always connect to the server.

 - Working around these problems for Webmapper's sake would also be useful for other use cases. For instance, embedded devices without UDP networking could use the same bridging functionality to connect to the network via an intermediate device, e.g. over software serial or bluetooth low energy. It would naturally lead to support for more transports.

What's hard about refactoring webmapper?

- This is probably the easy part. I haven't thought much about it.

What do you think?

TW