I think I can answer one of my own questions, Brian would be interested in hearing your experience (see below):
On Friday, May 12, 2017 at 10:11:54 AM UTC+10, Hedge Hog wrote: > > > > On Friday, May 5, 2017 at 5:14:42 AM UTC+10, Alexander Rössler wrote: >> >> Hi Brian, >> >> This is indeed a complex problem which Protobuf does not solve out of the >> box. This problem was one of the reasons why I started the Machinetalk GSL >> project. The protocol models describe to which Machinetalk message a >> Protobuf message belongs. >> https://github.com/machinekoder/machinetalk-gsl >> >> There is also code generator for the documentation in the repository. The >> generated docs can be found here: >> https://github.com/machinekoder/machinetalk-doc >> >> If you are more interested in this part of Machinetalk I recommend you to >> read >> http://machinekoder.com/machinetalk-explained-part-5-code-generation/ >> >> As for the messages in motcmds.proto -> most of the messages aren't in >> use by any service yet. Michael originally created them for the eventual >> replacement of NML by Machinetalk. >> > > Can you elaborate on the status of MT in terms of replacing NML? > According to Michael Haberler at [1]: "It is so bad I think 'fixing up' NML is hopeless - it's beyond repair." so that sounds like NML is to be retired completly. The discussions at [1] also outlines some of the 'business requirements' a replacement would need to provide. Unless I am reading this wrong it does not sound like the issue was that the message types or content was the pain point. That is, the set of instructions/actions and the data/information being passed around are OK. It is more the implementation detail/choices that were painful. Brian, I would be interesting to hear your experiences. E.g I wanted to do task A, which i expected to be a single message, instead I had to do K, then B, only then could I do A. Which is nuts because I had already done K and B in getting C. And it only makes sense (or you can only) do A from C. Hope that makes sense. Best wishes [1]: http://emc-developers.narkive.com/MNnPnur8/rfc-requirements-for-linuxcnc-middleware > Also what the intent/scope of MT is in terms of replacing NML? > > For example: > Is the goal to make MT messages map as exactly to NML messages? Or are you > retiring some NML messages? > Is the goal to make MT live alongside NML or will there be a hard cut over > from NML to MT? > > Are the requirements for MT settled? > > If it is not too late, can I ask that the use of required elements in the > protobuf messages be reconsidered? > > Specifically, in the light of the comments from the protobuf2 dev that it > was a mistake, and caused pain at Google: > > > https://capnproto.org/faq.html#how-do-i-make-a-field-required-like-in-protocol-buffers > > I'd suggest that if Google struggled with this we are guaranteed that our > users will find this painful. > Especially if the one of the use case is that users be able to hook up > various MK components/machines from time to time. > > I've developed some thoughts on the MT requirements, but haven't pushed > them because they are incomplete and I'd rather show a PoC. > If anyone wants to review or contribute let me know and I'll push more > regularly. > > >> Best regards, >> Alexander >> >> Am Montag, 1. Mai 2017 12:22:47 UTC-5 schrieb Brian Schousek: >>> >>> I understand the motivation and appreciate the beauty of the messaging >>> approach. I seem to be missing something that is probably obvious in the >>> mechanics however. I can understand individual elements of >>> publish/subscribe, encode/decode, the anddemo at >>> https://github.com/machinekit/pymachinetalk >>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fpymachinetalk&sa=D&sntz=1&usg=AFQjCNHgC5O9RyQQVRugtXpbQ2mrYp91Mw> >>> >>> makes sense to me, etc. >>> >> > Is this considered a canonical example of usage or more of a "hello world" > of MT? > > Best wishes > > Hedge > > I don't understand how to figure out how to initiate a channel containing >>> a given message. For example, I would like to monitor the messages as >>> defined in motcmds.proto >>> <https://github.com/machinekit/machinetalk-protobuf/blob/master/src/machinetalk/protobuf/motcmds.proto>. >>> >>> Are these message streams by definition flying around somewhere that I just >>> need to listen to? If so, where does it happen so I can look at the code >>> and further understand. Or perhaps these messages need to be turned on >>> somewhere? Or perhaps the messages are just defined here and it is left as >>> an exercise to the coder to generate them? >>> >>> In short, I feel like I understand the overarching intent, and also >>> understand much of the underlying detail, but I am not able to figure out >>> the connective tissue between the two. Would somebody please point me >>> towards enlightenment? >>> >>> Brian >>> >> -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
