API's missing

[ArcEye]

Issue by mhaberler Wed Apr 2 19:56:40 2014 Originally opened as https://github.com/machinekit/machinekit/issues/99

---

API's should cover programmatic access to core functionality, optionally remote

The core component interfaces currently are:

• HAL library: local, C++ and Python - no remote access
• halrmt: deprecated, unsuitable for programmatic access, poor code
• linuxcncrsh: a telnet interface, unsuitable for programmatic access, poor code
• schedrmt: based on linuxcncrsh, supposed to be an improvement over same, completely undocumented, no known uses, poor code
• the linuxcnc Python module: local access only, covers only a small subset of NML messages
• raw NML bindings: C++ only, limited remote access (no known uses ATM), very restrictive formats and use
• Web UI: there is a start with emcweb, with all the downsides of NML behind it.

Axis UI interfaces: axis-remote: specific to Axis and tkinter. Not a general API. Others: none known

Problem: programmatic/remote access to LinuxCNC is currently utterly inadaequate.

[ArcEye]

Comment by mhaberler Mon Apr 7 17:35:00 2014

---

After looking at this code (halrmt, linuxcncrsh, schedrmt), my conclusion is: delete it, start from scratch. It is just too bad, no point in wasting time on this.

A relatively sane C API is shcom.{hh,cc}: https://github.com/machinekit/machinekit/blob/master/src/emc/usr_intf/shcom.hh

it seems that basic API can be retained across the 'no more NML' transition.

Going forward, the submission of commands could be based on a zeroMQ/protobuf based RPC (remote procedure call). Operations requiring status retrieval through EMC_STAT will need to be adapted to the new style, and that is still shaking out. But that can come later.

restate problem: specify a zeroMQ/protobuf based RPC interface to LinuxCNC.