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?
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?