[Interest] Q_PROPERTY notification across processes?

[Mandeep Sandhu]

On Fri, May 17, 2013 at 9:55 AM, Constantin Makshin <cmakshin at gmail.com>wrote:

> 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.
>
DBus can work over the network. You just need a to specify a network
address instead of a local one for DBus communications. Though I'm not sure
about portability to other platforms as DBus is primarily used in Linux
based systems (I'm not sure about it's support on Windows). CMIIW.

Regards,
-mandeep



> 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
>>
>>
> _______________________________________________
> 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/f1dabcd3/attachment.html>