Hi Paul/Paula,
The software is part of a smart (electricity) grid control platform. I agree that on the github project there is also quite some code that is unrelated to the title of this Show HN post.
The particular thing I wanted to highlight is explained concretely here:
https://github.com/niekbouman/commelec-api/blob/master/docs/...
The application of the code is a networked control system, where, roughly speaking, many resources send messages to a central controller.
In the light of this "many-to-one" topology, the advantage of the approach taken in this project (essentially, sending an abstract syntax tree encoded in capnproto) over just sending a string, is that there is no parsing-step needed at the receiver, which saves time. (It is a real-time system)
The server program (I assume that you're referring to daemon.cpp), was added as a bridge between the more-powerful capnproto-based message format and a less-flexible but easier-to-use-for-non-experts (JSON-based) interface. However, what happens in this daemon should not be viewed as part of this Show HN topic.
For more details about the project, you could have a look at the following paper (open access)
https://infoscience.epfl.ch/record/210555?ln=en
The software is part of a smart (electricity) grid control platform. I agree that on the github project there is also quite some code that is unrelated to the title of this Show HN post.
The particular thing I wanted to highlight is explained concretely here: https://github.com/niekbouman/commelec-api/blob/master/docs/...
The application of the code is a networked control system, where, roughly speaking, many resources send messages to a central controller. In the light of this "many-to-one" topology, the advantage of the approach taken in this project (essentially, sending an abstract syntax tree encoded in capnproto) over just sending a string, is that there is no parsing-step needed at the receiver, which saves time. (It is a real-time system)
The server program (I assume that you're referring to daemon.cpp), was added as a bridge between the more-powerful capnproto-based message format and a less-flexible but easier-to-use-for-non-experts (JSON-based) interface. However, what happens in this daemon should not be viewed as part of this Show HN topic.
For more details about the project, you could have a look at the following paper (open access) https://infoscience.epfl.ch/record/210555?ln=en