On Oct 19 2014 7:06 AM, Jeff Epler wrote: > 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.
nice. I had not needed this functionality yet, but I can see having use of it in the future. > 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. sounds good. > (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) I have seen examples, but I think you are correct that they are easier. > 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 sounds good, but I would hope to see something that does not require java to support a C-based API. I'm thinking "what is the minimal tool-chain for an embedded control system" > 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. I think this is a big enough change that it should be 3.0 and 3.?. I can also imagine that a few people are going to want the deprecated classes around for awhile, and there may be reasons to have a few releases before it is removed from the source tree. If the migrated NML code is moved into what is in essence a module, then there may be no reason to formally depricate it for quite some time. Speaking for myself, I have no need for the old protocols if the new ones "just work", but I can see others might have some old code that needs them. Hope that is helpful. EBo -- ------------------------------------------------------------------------------ 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
