[Interest] Q_PROPERTY notification across processes?

[Constantin Makshin]

Charley said that in most cases his applications will be run on different
computers, so D-Bus won't help him since it doesn't work over network.
On May 17, 2013 8:01 AM, "Tony Rietwyk" <tony at rightsoft.com.au> wrote:

> Hi Charley, ****
>
> ** **
>
> You didn't say which type of systems this will be running on? ****
>
> ** **
>
> What about QtDBus using a direct connection between the applications,
> instead of the system-wide bus?  ****
>
> ** **
>
> Even if that doesn't work for you, it has solved many of the same
> problems, and needed over 20,000 lines of code! ****
>
> ** **
>
> Regards, ****
>
> ** **
>
> Tony****
>
> ** **
>
> ** **
>
> *From:* interest-bounces+tony=rightsoft.com.au at qt-project.org [mailto:
> interest-bounces+tony=rightsoft.com.au at qt-project.org] *On Behalf Of *Charley
> Bay
> *Sent:* Friday, 17 May 2013 11:27 AM
> *To:* Qt Interest
> *Subject:* [Interest] Q_PROPERTY notification across processes?****
>
> ** **
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130517/f415144d/attachment.html>