[Interest] Q_PROPERTY notification across processes?

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

    // ...
}

Arne wrote:

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

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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130519/f6422e78/attachment.html>