[Development] QtRemoteObjects (was Replicant)
charleyb123 at gmail.com
Sun Oct 26 15:07:41 CET 2014
> Sayeth Simon:
> On the other hand I think it is critical for Qt's success to also support
> > cases that leave our little universe (of Qt). And that means either
> > something yourself and convincing others to adopt it or adopt a
> > technology/approach that already has existing mind share. For distributed
> > objects architectures I do like the idea of supporting wire formats that
> > existing mind share and I also do think it is very important to make the
> > programmers aware of the distribution.
> Sure. I agree in concept. But how are you suggesting we go about this?
> My resistance comes from several factors:
> 1) I think what you are proposing is what D-Bus brings to the table. By
> focusing on the Qt side, I think remote objects is easier to use than
> D-Bus, but is also not seen as competing with it. You risk both by making
> it more general.
> 2) What you are proposing is a massive increase in scope, which obviously
> takes a lot of time/resources to accomplish. Is Digia offering to help?
> 3) As stated, the existing code is spread throughout all of Qt. I assert
> that any new wire format support needs to be spread throughout Qt as well.
> Otherwise you have a maintenance nightmare trying to keep up with changes
> to all of the various types of objects.
> Unless you have a solution I'm not seeing, I think the best thing to do is
> try to future-proof remote objects so such a change is possible down the
Agree with Brett.
I think this is a "vision/mission" thing, as D-Bus and QtRemoteObjects are
doing different things, but as noted there happens to be some "overlap".
Regarding the "future-proof", I'd vote on a plain-text
serialization/synchronization of QVariant across the wire, possibly with
user-data type extensions for custom plain text to/from for state
serialization across the wire. Plain text tends to be quite robust, and
future-proof, and it's often useful for debugging anyway, even in the case
where a binary protocol is available. Good examples are things like "date"
and "time" and "color" -- the plain text version is well-understood and
forever future-proof, independent of native binary storage. Most of the
automation and LIMS systems (lab information management systems) actually
stay plain-text for production, and that's what they use in production to
simplify integration across vendor devices and instruments.
It might not be practical for high-speed/high-volume data to be plain text,
but most systems aren't that. QtRemoteObjects sitting on plain text (like
JSON) might enable alternative "foreign-point" implementations (such as for
other non-Qt libraries or languages).
The most "ideal" might be a "slow-plain-text" protocol, and a "fast-binary"
protocol, where the user can toggle between them based on their
need-for-speed. But, of course, that's double the work. ;-)
So, I think there are really good points here, but my intended "first use"
is QtRemoteObjects with Qt on "both sides" for transparent synchronization.
In this case, I actually don't care about the details. I want the library
to do all the cross-process details, so I don't need to. That's what makes
it really "shine" as a novel high-value thing, IMHO.
Further, if we did this, I could still write "MyProprietaryLib" on the
"foreign-point" to hook into other systems. It would link Qt, and expose
the QtRemoteObjects API through my new API using MyWeirdLanguage.
Regarding the foreign-point not linking Qt (such as for embedded where no
Qt might be available), yes, we're back to discussing something like a
plain-text protocol where someone could re-implement using that protocol.
> > This is clearly something where philosophies and opinions differ, so a
> > subject for a healthy debate of what we should focus on in Qt, as we try
> to to
> > make software development easier.
> I think the discussion needs to be whether Qt will accept an alternate or
> additional method of marshalling data types. But I guess that is up for
I'll follow discussion here closely. My impression is that we'll
eventually need/want to "centralize" marshalling/serialization for
QtRemoteObjects, possibly eventually allowing user-custom-type extensions
for synchronizing custom user-state.
It would either be centralized through something like a moc-generation that
handles the details for each type, or through a centralized "marshaller"
that is "aware" of the serialization details for each type.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development