POC: nodejs control plane (Feedback wanted)

[Julusian]

I am very interested in feedback from others on whether they think this is a good idea or not.
The code is far from complete or ready, this is still very much at the proof of concept stage.

If anyone has any questions or concerns please share them here. Or you can PM me on the forum if you have something you would prefer not to say/share publicly.

---

I've had this idea for a while now, which is to replace the C++ AMCP implementation with nodejs. This spawned from thinking about #826 where the scope grew quite a lot, and frustration with the current AMCP parsing, particularly for producers/consumers which have many properties. Additionally I was thinking about adding a http api as an alternative to AMCP, but didn't find a http server that looked decent and wouldn't be a burden as a dependency which also had an openapi generator.

This nodejs control plane would provide a few key benefits:

• It makes supporting other protocols much easier, the whole nodejs ecosystem can be utilised
  • Such as http with openapi definitions.
  • Adding security will be easier and can be more easily verifiable
• It makes the control/api layer more accessible to developers
  • Perhaps to make a custom api for a locked down/limited playout system
  • There are a couple of github issues talking about server-side scripting, which would be more achievable with this.

Also some downsides:

• it adds complexity in translating nodejs types to c++
  • there is a risk of new bugs being introduced there, but that is the same for any new feature.
• this complicates the building and distribution.
• there is more risk of old versions of casparcg being unbuildable in the future. I'm not sure how much more, based on my experience of compiling 2.0.7 which needed old tools a couple of years ago.

A key thing to note is that no frames go near the nodejs portion. When loading a producer we do pass the pointer to nodejs, but not in a way that it can be inspected or operated on. So this should have no impact on the ability of caspar to do playout well. This only impacts the amcp part, and producer/consumer creation up until they are added to the channel.

This does run if compiled from source (on linux), and existing clients can connect and work as expected.
If we go ahead with this, more work is needed to:

• Figure out packaging/distribution
• Ensure everything AMCP is implemented
• Reimplement OSC (data is in js already, just needs piping into the osc library)
• General tidying of the new code, it is quite a mess
• Finish the config xml parsing, and config propogation to modules
• Remove the remaining amcp parsing from modules, nodejs should handle that with it generating a ptree structure to be used by the c++
• Consider combining the scanner into this nodejs layer, probably as a worker_thread. That will simplify setup and deployment, and being in a thread will minimise risk of impact.