As happens so often, the topic of linuxcnc's API for user interfaces
came up. This time it was in the context of reported bugs like
https://sourceforge.net/p/emc/bugs/328/ and /395/.
(The summary of those bugs is: the serial number method for UIs to ensure
a message is acted upon by task simply does not work when there is not
just one UI. No simple modification will make it work, and no one in
the project in 10+ years has taken the time to understand NML with the
depth necessary to suggest a correct approach.)
Last night at the Texas fest, Chris Radek, Seb Kuzminsky, and I
brainstormed an outline of an incremental way forward, which will take
at least two releases before the ultimate goal of transitioning from NML
to a different IPC method. In the initial step, the new IPC method
does not even need to be selected.
I think this is a good plan and I intend to allocate time to work on
it. Hopefully we'll be able to further subdivide it in ways that let
several of us collaborate, because it's by no means a small project.
Step 1. Make a "C" API based on the one declared in src/emc/usr_intf/
shcom.hh the official API of user interfaces. Rewrite at least one
in-tree UI use this new API. Deprecate the direct inclusion of
nml-related headers and use of nml APIs in out-of-tree UIs.
Hypothetically, this would all go in a new header <linuxcncui.h> and all
the APIs would have a hal/rtapi-like naming convention with a common
prefix and in the lowercase-and-underscores style, such as
lui_send_estop() // like today's shcom sendEstop()
(lui == linuxcnc ui). Also make sure it's possible to build an external
UI by including <linuxcncui.h> and linking with -llinuxcncui.
(By "C" API, I mean one that has only C linkage, not C++. Even today,
most scripting languages are easier to extend with C APIs than C++ APIs.
The implementation can be in C++ and must be while the IPC is NML)
Step 2. Experiment with different NML replacements such as json or
protobuf, simply by
a. writing an implementation of liblinuxcncui that use the proposed
IPC method
b. and writing a server implementation which either lives directly
in task, or as an intermediate step writing it as an NML client to
an unmodified task
Step 2'. Rewrite all in-tree UIs to use <linuxcncui.h>
Step 3. Actually select and incorporate a new method, moving it to task
if it wasn't in step 2. Remove NML, which was deprecated back in an
earlier LinuxCNC release in step 1.
Step 4. If the new IPC method enables new things, like e.g., selecting a
variable rate to stream position feedback (enhancing the backplot),
incrementally add these to the C API as these new features are
developed.
In the end, we can decide whether our public API is <linuxcncui.h> or
the IPC method we select later. Advantages of the former are that we
can later change the IPC method without affecting existing UIs.
Advantages of the latter are that with a frequently-implemented
transport like json-over-tcp, we enable writing UIs that don't even
have to use our API implementation; they can just e.g., read json
data and use it directly.
Since step 1 involves a deprecation of a feature and step 3 involves its
removal, they have to be in separate releases, say 2.8 and 2.9,
depending when we get on the ball and actually do the work.
Jeff
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
