making hls ready for talking to multiple clients #4667
Description
Hi everyone. Upon popular request (looks frightened at @fendor) I will hereby create a small tracking issue for making HLS ready for multiple clients. Here are the things that need to be done:
- make HLS accept URIs that are not file URIs. This is currently being implemented in replace usages of NormalizedFilePath with NormalizedUri wherever possible #4622
- fix some concurrency issues that only come up when you connect multiple clients concurrency bug fixes/ improvements #4663
- perhaps the most controversial one; integrate a websocket server. This is actually the first "actual" implementation of the proposed feature. The proposed changes are tracked in make hls speak websocket #4666. Of course, the websocket communication would be factored out to a separate module but the general idea is to abstract the "communication" away and then allow the main entry point to also spawn multiple instances of the server and talk to them via newly passed "communications"
While they're not finished (except for task 2 which only needs merging), the above three things are working in the sense that HLS talks to multiple clients via websockets in parallel.
Open problems:
- the main problem is sandboxing:
- How do we isolate GHC sessions (actually something that I would like to ask someone with more knowledge, perhaps @wz1000?)
- How do we make sure people don't make HLS go crazy with template haskell/ System.Process etc etc (something to figure out in the actual sandbox)
- How to add a feature of limiting new connections to HLS based on current memory usage (problematic because it's not exactly HLS' task to do this in theory but in practice it's really the only place to do it)
- how do we split up communication so that HLS doesn't do things it shouldn't do (@fendor really doesn't want to see a dependency on
websocket)