[Development] QtRemoteObjects (was Replicant)

[charleyb123 .]

>
> Sayeth Simon:
>
> On the other hand I think it is critical for Qt's success to also support
> use-
> > cases that leave our little universe (of Qt). And that means either
> building
> > 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
> have
> > existing mind share and I also do think it is very important to make the
> > programmers aware of the distribution.
>

Respondeth Brett:

> 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
> road.
>

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).

Just guessing/speculating.

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.

<snip>,

> > This is clearly something where philosophies and opinions differ, so a
> perfect
> > 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
> debate!
>

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.

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20141026/14e4fa21/attachment.html>