Hello Charley,
this sounds like an interesting thing to code! I think your basic design
ideas are sound, i.e. have a "dispatcher" on both ends that connect to
each other in some way and exchange information using a not too
complicated protocol.
Some questions/points to consider:
- do you need to communicate object creation/destruction?
- how often do the properties change?
- what amount of data are we talking here (kB/s)?
- do you need synchronous communication or is async OK?
You could always roll your own solution for this kind of thing, but I
believe there should be a ton of ready-made solutions already. As a
numerics guy, I know of MPI, which provides a ton of one-to-one,
one-to-many, many-to-many communication routines; however, I'm not sure
whether this is a good solution for you.
Cheers,
arne
On 05/17/2013 03:27 AM, Charley Bay wrote:
I have a C++ QObject-derived class that exposes properties for use in
QML, works fine (Qt5).
WHAT I WANT:
I would like to instantiate an "instance" of this class in each of two
processes, where changes in one "notifies" the other (in the other
process). This is logically something like
"local-instance-reflection" to a remote instance in a remote process.
(I could create a second class-type if needed, but current
implementation suggests I could instantiate the same class type on
each side.)
My current thoughts are to use a "socket" between the two processes,
where the objects "agree" on a unique identifier that represents that
"reflected-instance" in each process. Then, the implementation would
trigger "onChange" operations in the remote-instance from
property-changes in the local-instance. There would be many of these
"reflecting-pairs".
This "implementation-plumbing" would probably be through some C++
implemented dispatcher, where one would be instantiated in each
process, and be responsible for the serialization for
state-changes/notifications between the processes (read/write), and
routing the notification to the object in the local process.
A concern I have is that there will be *many* of these pairs
(thousands, possibly tens-of-thousands), and I don't know if the
approach would scale-well for lots of notifications.
Does this design seem reasonable?
Do you have thoughts on an alternative?
It seems like the "Q_PROPERTY" notification through QML would be an
interesting mechanism to enable this "generic-cross-process"
event-based-synchronization.
I can't use shared memory, as these processes will typically be on
different machines.
--charley
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
--
Arne Dirks
Softwareentwicklung
IAT International Algorithmic Trading GmbH
Tel: 040 711 86 75-22 | Fax: -10
Am Knick 4 | 22113 Oststeinbek | www.iathh.de
Geschäftsführer
Peter Vorrath
Georg von Wiedebach
Gesellschaftssitz: Oststeinbek
Registergericht: Lübeck | Registernummer: HRB 7454HL
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
