[Interest] Q_PROPERTY notification across processes?

[Arne Dirks]

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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130517/72966d6e/attachment.html>