[Interest] Q_PROPERTY notification across processes?

[Charley Bay]

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

[Constantin Makshin]

If these processes will be on different systems, then I doubt that you have
any choice. :-)

Post by Charley Bay
I have a C++ QObject-derived class that exposes properties for use in QML,
works fine (Qt5).
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
http://lists.qt-project.org/mailman/listinfo/interest

[Tony Rietwyk]

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=***@qt-project.org
[mailto:interest-bounces+tony=***@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

[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.

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****
** **
** **
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
http://lists.qt-project.org/mailman/listinfo/interest

[Mandeep Sandhu]

Post by 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.

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

Post by Constantin Makshin

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****
** **
** **
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
http://lists.qt-project.org/mailman/listinfo/interest

_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Thomas Sondergaard]

Post by 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.
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.

QtDBus works fine on Windows - at least in 4.8, I don't know about 5.0.

Of course you can't use the binary Qt SDKs as D-Bus is not native to
Windows. You will have to build D-Bus yourself on Windows and then build
your own Qt against it. It is straightforward and there are no quirks to
speak of.

Thomas

[Mandeep Sandhu]

On Fri, May 17, 2013 at 8:40 PM, Thomas Sondergaard

Post by Thomas Sondergaard

Post by 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.
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.

QtDBus works fine on Windows - at least in 4.8, I don't know about 5.0.
Of course you can't use the binary Qt SDKs as D-Bus is not native to
Windows. You will have to build D-Bus yourself on Windows and then build
your own Qt against it. It is straightforward and there are no quirks to
speak of.

Ok, thanks for the info. Good to know DBus works well on Windows.

Regards,
-mandeep

Post by Thomas Sondergaard
Thomas
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Constantin Makshin]

Oh, yes, you're right. I was confused by the "Introduction to D-Bus"
section of the D-Bus web site, probably some parts of it are too outdated.
Sorry for spreading that confusion. :-)

Post by Mandeep Sandhu

Post by 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.

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

Post by Constantin Makshin

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****
** **
** **
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
http://lists.qt-project.org/mailman/listinfo/interest

_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[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

Post by Charley Bay
I have a C++ QObject-derived class that exposes properties for use in
QML, works fine (Qt5).
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
http://lists.qt-project.org/mailman/listinfo/interest

--
Arne Dirks
Softwareentwicklung

IAT International Algorithmic Trading GmbH
Tel: [phone] | 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

[Charley Bay]

Thanks to all for the comments in this thread (see below). They have been
very helpful. Apologies for my lateness-in-response, (I've been traveling).

<snip, I want "Q_PROPERTY"-based triggering of state notification/update
across-processes for individual QObject-derived "mirror-instances" from
within QML>

MOTIVATION: This is "curious" to me, as I think the "Q_PROPERTY"
notification mechanism can be centralized into a "single-point" of
notification across process-boundaries (e.g., I can code it once into a
library, and I would do "absolutely-nothing" to enable "cross-process"
sharing of state for (QML) objects-with-properties.)

For the casual user, actual code would look something like this:

// FILE: MyServer.cpp
int MainForServer(void) {
// Create local instances of "MyQObject" that will
// have their existence-and-properties exposed
// through QML.
MyQObject* my_qobject0 = new MyQObject();
MyQObject* my_qobject1 = new MyQObject();

// Create our "dispatcher" that manages the
// objects that we "expose" for other processes
// to "mirror".
MyMirrorDispatcher my_dispatcher;

// "Register" our "local-instances" so they are
// "created/mirrored" in remote processes.
my_dispatcher.registerLocalInstance(my_qobject0);
my_dispatcher.registerLocalInstance(my_qobject1);

// ...any "Q_PROPERTY" state-notifications will
// now "echo" to remote processes, and our local
// "my_qobject0" will receive notifications from the
// other processes that have their own instance
// that "mirrors" our local-instance.

// ...
}

// FILE: MyClient.cpp
int MainForClient(void) {
// Create the "local-dispatcher" instance that "finds"
// the "server" whose state it should "mirror".
MyMirrorDispatcher my_dispatcher(/*...server-info...*/);

// The "my_dispatcher" will "find" the server, "see"
// it has (several) instances, trigger their local instantiation,
// and ensure local "onChange()" operations echo back
// to the server, and that local instances are "notified"
// for changes in the object on-the-server.

// ...
}

Post by 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.
- do you need to communicate object creation/destruction?

Yes, the "local-dispatcher" must create local instances for each one it
"sees" on the server, and those are arbitrarily created on the server.
Further, when it "disappears" from the server, it should similarly be
removed from the local-client.

At the moment, I don't care about creating local-instances on the "client"
that are "mirrored" to triggered-instantiations on the server (as in a true
peer-to-peer), but it seems like that would be little extra work.

- how often do the properties change?
Frequently. Envision objects for a "build-system" (hundreds or thousands
of instances), and properties change several times during the
"make-current-the-individual-object".

This means for an individual object, something like "several times a
second" or "several times over several seconds" (or less frequent) for each
object, and not hundreds-of-times a second. However, with hundreds of
objects, that may be "hundreds-of-notifications-a-second" across the
process-boundary.

- what amount of data are we talking here (kB/s)?
Small for each notification. In general, each "notification" should be
simple state-changes for a "Q_PROPERTY" value, like a single "QVariant"
(int/enum, QDateTime, QString, etc.)

I think it should be fine to restrict it to "small" like demanding it fit
inside a single UDP-packet (or something). So, hundreds-of-bytes should be
plenty (most of the time), although I expect the common case should be
"dozens-of-bytes" for the data payload.

For example, Twitter restricts messages to 140 message-chars, with the
system reserving an additional 20 chars (160 chars total). I think that
should be fine for the notification I need (and most
property-notifications).

However, I realize Twitter ultimately allows packets up to 32K per
notification. It might be interesting to allow that on this system (such
as for sending small images), but that should mostly be uncommon.

- do you need synchronous communication or is async OK?
Asynchronous. However, order-of-delivery could be important (I don't want
an out-of-order notification to imply a stale-state, so "timestamp" might
be handy in the implementation for the client to resolve
"stale-notifications" that it should ignore.)

You could always roll your own solution for this kind of thing, but I

Post by Arne Dirks
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.

Yes! I'd rather have a simple/cross-platform already-available thing for
this. I just need something that can "work" in the case where "server" has
many objects, and some are "noisy" (e.g., I don't want to "get-behind" in
the network traffic sending/receiving).

Suggestions in this thread (I'm researching further now):

- MPI (Arne suggested)
- QtDBus (Tony suggested)
- zeromp (Yves suggested)
- QxtRpc (Alex suggested)

Interesting!! I was unaware of "zeromp", hadn't looked into MPI, and didn't
think about QxtRpcService. (I have lots of reading to do!)

Mandeep (using Qxt's IPC/RPC) -- how many notifications-per-second does
your system have, and do you have a feel for how it will scale (especially
for the use model described above)?

As an aside, it seems like this kind of interface would be useful in a
number of settings. It seems like the Q_PROPERTY/QML
"notification-plumbing" allows "FOR-FREE" this type of cross-process
synchronization. If I get it working (seems do-able), I might be able to
contribute the code to the Qt community (in the event the Community thinks
it to be non-stupid as an approach). -- I was just curious if anybody had
this idea already, or (better-yet) had coded it already. ;-))

Thank you all for your input! Looks like I have lots of reading to do...

;-)

--charley

[Stephen Kelly]

Post by Charley Bay
If I get it working (seems do-able), I might be able to
contribute the code to the Qt community (in the event the Community thinks
it to be non-stupid as an approach). -- I was just curious if anybody had
this idea already, or (better-yet) had coded it already. ;-))

I've done it with QtDBus before. See this though:

https://bugreports.qt-project.org/browse/QTBUG-15052

It's probably still not fixed in Qt 5. (but maybe I should fix it there soon)

Thanks,

[Mandeep Sandhu]

Post by Charley Bay
- MPI (Arne suggested)
- QtDBus (Tony suggested)
- zeromp (Yves suggested)
- QxtRpc (Alex suggested)
Interesting!! I was unaware of "zeromp", hadn't looked into MPI, and
didn't think about QxtRpcService. (I have lots of reading to do!)
Mandeep (using Qxt's IPC/RPC) -- how many notifications-per-second does
your system have, and do you have a feel for how it will scale (especially
for the use model described above)?

Our usage was not heavy, as most of the communication happens on user
action and when it happens its probably just 2 or 3 invocations per second.

QxtRPC is not suitable for high volume traffic as the signals are
serialized into 'text' streams and sent over the comm channel.

For you use-case (and since you want to make it a generic solution), I
think DBus is the best bet as it uses a binary format for data transmission
which is much more efficient than what QxtRPC uses. DBus offers a lot more
functionality like object intorspection which can be used by others to see
what properties are exposed by such QObjects. Also hooking up signals using
proxy objects provided by QtDbus is very easy (you can simply chain out
your property change signals as Dbus signals).

What you have to see is whether such notifications happen over a bus or in
a peer-to-peer fashion. If there are a lot signals being generated then
it's best to avoid the bus (you'll probably use session bus as system bus
should be used only for system events) to avoid affecting other
applications.

Just my 2 cents.

Good luck,
-mandeep

Post by Charley Bay
As an aside, it seems like this kind of interface would be useful in a
number of settings. It seems like the Q_PROPERTY/QML
"notification-plumbing" allows "FOR-FREE" this type of cross-process
synchronization. If I get it working (seems do-able), I might be able to
contribute the code to the Qt community (in the event the Community thinks
it to be non-stupid as an approach). -- I was just curious if anybody had
this idea already, or (better-yet) had coded it already. ;-))
Thank you all for your input! Looks like I have lots of reading to do...
;-)
--charley

[Yves Bailly]

I have a C++ QObject-derived class that exposes properties for use in QML, works fine (Qt5).
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.
[...]
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.

I found this project recently:
http://www.zeromq.org/

Maybe it could be useful for what you're looking to achieve. I've not yet tried it though.

Hope this helps.

[alexander golks]

Am Fri, 17 May 2013 08:16:36 +0200

Post by Yves Bailly

I have a C++ QObject-derived class that exposes properties for use in QML, works fine (Qt5).
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.
[...]
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.

http://www.zeromq.org/
Maybe it could be useful for what you're looking to achieve. I've not yet tried it though.
Hope this helps.

what about something like:

"Qt Signals and Slots over the air"
http://libqxt.bitbucket.org/doc/tip/tech-ipc.html

though i didn't had time to look into this myself, yet...

alex

[Mandeep Sandhu]

Post by alexander golks
Am Fri, 17 May 2013 08:16:36 +0200

Post by Yves Bailly

Post by Charley Bay
I have a C++ QObject-derived class that exposes properties for use in

QML, works fine (Qt5).

Post by Yves Bailly

Post by Charley Bay
I would like to instantiate an "instance" of this class in each of two

processes, where changes in

Post by Yves Bailly

Post by Charley Bay
one "notifies" the other (in the other process). This is logically

something like

Post by Yves Bailly

Post by Charley Bay
"local-instance-reflection" to a remote instance in a remote process.
[...]
A concern I have is that there will be *many* of these pairs

(thousands, possibly tens-of-thousands),

Post by Yves Bailly

Post by Charley Bay
and I don't know if the approach would scale-well for lots of

notifications.

Post by Yves Bailly
http://www.zeromq.org/
Maybe it could be useful for what you're looking to achieve. I've not

yet tried it though.

Post by Yves Bailly
Hope this helps.

"Qt Signals and Slots over the air"
http://libqxt.bitbucket.org/doc/tip/tech-ipc.html
though i didn't had time to look into this myself, yet...

We're using Qxt's IPC/RPC module in our project. It's simple and easy to
use and works well over different platforms. We're using it to communicate
with a different process running on the same machine.

We went along with this and not use DBus (which provides MUCH more
functionality) because of concerns about DBus' availability on other
platforms (primarily Windows). Qxt is 100% based on Qt and relies on local
Unix domain sockets for functioning (which is there on all platforms).
Also, QtDBus is _comparatively_ more cumbersome to use.

I think your usecase where you want to inform the other process about
property changes can make use of Qxt RPC's signal/slot as it can
'serialize' your signal emissions and invoke slots in other processes.

HTH,
-mandeep

Post by alexander golks
alex
--
/*
* printk(KERN_ERR "%s: Something Wicked happened! %4.4x.\n",...);
* linux-2.6.6/drivers/net/sundance.c
*/
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest