OK, have been thinking if the shift to the flatbuffers over protobuf would have any positive effect.
Given the fact that so far all Machinetalk messages are status updates or commands or logs or similar, in other words, no big blobs of arbitrary data, so are not used for object storage, but are pretty much copied out in the function call body, there could be benefit in the zero-copy property of the flatbuffers and the fact, that serialized buffers are mutable (if I understand it correctly). It could be used to go away with multipart messages as they have its own problems of need for multiple reads from a socket, inability to set queue limit to 1 (turn off queueing) and general ugliness. You would use one message of type Container for all frames (like zproto idea). It would need to have allocated scratchpad memory for the routing needs of different services. (Like messagebus uses frames for address storage.) Then, if the zero-copy idea works as I think it works, in a pass-through situation, you would get the message, look up the address and pass the same buffer to sending socket with no need for deserialization to other object and reserialization to buffer. However, given the size growth of flatbuffer's buffers and work needed I am not sure the gains would be worth it. You would probably piss off a lot of people. Cern. Dne sobota 20. dubna 2019 7:49:24 UTC+2 auto-mation-assist napsal(a): > > I have been looking for the same information for a while and have looked > at all the links listed in the past. My purpose being to design a remote > gui that strictly interfaces via a network. ZMQ would also be used. I have > done some python and qtpy work with linuxcnc but my goal is to use a remote > gui that can run on windows. > > I have an interest in machine kit since a lot of work has been done on > remote gui ability but not a fan of protobuf. Thus for me I will replace > protobuf with flatbuffers and at some point in the future and also start > thinking about perhaps replacing NML with flatbuffers. > Info on flatbuffers is at: https://google.github.io/flatbuffers/ > > Converting the established proto files to flatbuffers files apears to be > easy which simplifies things. > Info on speed comparisons: > https://google.github.io/flatbuffers/flatbuffers_benchmarks.html > > Anyway these are some of the the things going through my mind that I > anticipate working on this year. > > On Sunday, April 14, 2019 at 8:56:53 PM UTC-8, Chris Morley wrote: >> >> I am interested in ZMQ in linuxcnc and thought i might look at >> machinekits implication. >> I don't see any docs. >> >> Thanks. >> Chris M >> > -- 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.
