> On 16 Jan 2017, at 16:14, Oswald Buddenhagen <[email protected]> wrote: > On Sat, Jan 14, 2017 at 05:07:30PM +0000, Stottlemyer, Brett (B.S.) wrote: >> >> If you really did mean other object distributions systems, which ones are >> you thinking of? Microsoft’s Component Object Model is interesting, but >> I’m really not sure how to integrate with it. >> > i was thinking of corba, the example i already mentioned. but i don't > know what is currently relevant in the industries we're targeting.
Maybe DDS, which is also from Object Management Group, which uses IDL in approximately the same way, but is extended to support both multicast and point-to-point communication and has the pub-sub metaphor. Unlike many alternatives, it’s peer-to-peer. We have one customer who uses it extensively, so there was a back-burner idea to integrate some sort of support for it in Qt. https://en.wikipedia.org/wiki/Data_Distribution_Service Speaking of pub-sub, I’ve been hearing about MQTT lately, but haven’t tried to use it. Seems it’s popular with the IOT crowd for now. Has the same disadvantages of D-Bus (as it’s usually used): only TCP and only via a message broker, so it’s not decentralized enough to be truly resilient. > well, in the worst case, the data can be simply sent along via blobs. of > course, that kind of defeats the protocol's native type support, but it > will work just fine if qt is on both ends. Exactly… it’s going to end up as some sort of byte stream anyway. The correct usage of D-Bus wire protocol can (and should) be refined over time, but at least you have somewhere to start. I’m not convinced that D-Bus is everything an RPC system should be, but it happens to be popular. Yes it can run across the network - I did that experiment ages ago. That usage is not “supported” mainly because the author didn’t want to bite off more than he could chew; CORBA was already prior art at the time, and it’s clear that distributed object systems are way more complex than IPC on one machine. But I think if you can get away with using the same wire protocol for that too, why not… at least the XML is easy to parse, as Ossi points out. (Although if one was reinventing it today, why use XML… maybe JSON? maybe a binary XML-like self-describing representation. But all of those can be converted anyway.) And you only need it for introspection; you are also free to hard-code your own usage of the wire protocol on both ends without having to write XML first. What seems to be unique from what you’ve said about qtro so far is automatic serialization without having to write all the stream operators, in cases where they don’t already exist, right? But that’s just a way of getting a byte array, which can indeed be a blob as long as your decoding technique is universal. So I do like the idea of this being turned into a layer which can run on top of various RPC and object communication mechanisms instead of only one new black box. Ideally it could run on all of them, but that’s many years of work, of course. Later, communicating with non-Qt processes could even be possible. Even if you don’t see it as a goal yet, maybe someone will. >> This has been discussed in the past. >> > indeed, google protocol buffers as a generic data serialization format > have been previously proposed here, but i don't remember the context. And from what I read they suck… too much code is generated, which bloats the application and takes too long to compile. Google reinvents the wheel too sometimes, just because they can, and it’s not always elegant, nor does it always pick the tallest giants to stand on their shoulders. The author went on to write CapnCrunch, which I hear good things about. Still didn’t get around to trying it. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
