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" <t...@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...@qt-project.org [mailto: > interest-bounces+tony=rightsoft.com...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
