<I am so not a fan of top posting, but I didn't want to confuse the order by bottom posting.>
I agree with Ken. I think it is a win-win approach. Michael, I don't know what the answer is on the god-awful licensing problems. It is an issue that seems insoluble; even the Linux kernel developers still argue about it. As for the technology, we must keep in mind that the RCS/CMS/NML code is probably the oldest (and seemingly least changed) artifact in our codebase. It predates introduction of the HAL. What we now see as limitations were great advances back in the 1980s/1990s. Time moves inexorably forward and so does technology. So should we. I think your list of wants and warrants is very good. It seems to me I once suggested to you that you should post your ideas on the Wiki---perhaps under "The future of LinuxCNC". Maybe I'm just dreaming I did. Either way, I was just looking through the Wiki and I didn't seen them. Why not just take what you wrote here and make it a page in the WIki? Regards, Kent On 8/7/2012 5:49 PM, Kenneth Lerman wrote: > The only real problem with this is that no one is using RCS... for > anything new. Of course, that might be an advantage. > > A phased development > 1 -- Implement the something new with a set of the same existing > interfaces, so we have a parallel (RCS like) way of doing what we do now. > > 2 -- Implement some new, useful stuff using the new technology. > > 3 -- Gradually re-implement the stuff that uses RCS to use the new > technology. > > 4 -- Pull out the old technology. > > Ken > > > On 8/7/2012 5:29 PM, Michael Haberler wrote: >> a few semi-related notes: >> >> I'd been looking into potential alternatives to the RCS/CMS/NML code in >> Linuxcnc for different reasons: >> >> - the restrictions are substantial: fixed message size, a very limited >> interaction model (no really usable remote procedure call, no >> publish/subscribe interaction, an arcane approach to serialization, remote >> command injection etc) >> - a really distibuted solution should address sharing HAL information across >> machines just alike, not just NML messages with ad-hoc HAL contents copied >> around at the C level >> - it should support late binding, i.e. contents of messages defined at >> runtime (no need to recompile because some field/HAL bit is added) >> - it should support easier and mostly autogenerated binding to at least >> Python >> - the current NML code is C++-based and hence not kernel-compatible, which >> is an issue at the userland/RT component boundary (message transcoding >> required, eg. in src/emc/motion/usrmotif.c) >> - the current code is substantial, but only a minimal part of the >> functionality is currently used, and knowhow on it is scarce >> - the current coding style, and mode of use encourage a piecemeal migration >> to a single machine model (shared filesystem assumed, poor distribution >> options etc), which is somewhat driven by the NML framework's limitations >> - some recent ideas about a future linuxcnc structure would suggest a more >> close interaction of interpreter ad realtime modules, which has >> repercussions on the communications framework, and it is unclear to me >> whether NML will be on the help or issue side >> >> this is btw a very similar laundry list like realtime middleware used e.g. >> in stock market transactions, like Tibco Rendezvous >> >> the best list of candidate components I could find was: >> >> - zeromq as messaging framework >> - status distribution by reliable multicast (openpgm, already integrated in >> zeromq) >> - google protobuf for message coding/decoding and language binding >> - nanopb, a RT-module compatible protobuf library (if one were to use a >> unified message format from wire down to RT/userland comms) >> >> A showstopper is licensing - zeromq is GPLv3 and I understand that excludes >> its use in linuxcnc >> >> -- >> >> I'm writing this up because it might help someone looking for suitable >> components. >> >> Other than that, it's a thought experiment, not a proposal, and no pending >> patch if you will. >> >> - Michael >> >> >> >> >> >> >> > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
