Services calling back to clients

[Ross Burton]

Hi,

I've an application in which clients can request the server to perform a
lengthy task, and report the results back to the server.  A normal
call/return process isn't usable as the results are delivered
incrementally.  I can't use signals as they get send to every process
which is listening, and as these signals could be quite frequent and
large (my tests easily transfer 2Mb) this is quite an overhead.

Using the latest DBus and a nasty hack, I had a solution: object paths
sent to the server were not demarshaled into a local object, but into a
proxy with a destination which is the source of the message, so the
server-side code can simply call dbus_g_proxy_set_interface() and treat
it like any other proxy.  This removes the ability to send paths to the
server as server-side objects, but I was going to work on that later
with some metadata.

Colin's latest patch to the bindings (not committed as yet) removes the
automatic marshaling for performance reasons, and clients/servers send
literal paths.  This is fine for most cases as creating a proxy is
trivial, but it breaks my case: on the server in the bound methods I
have access to the path but not the original message, so I can't create
a proxy back to the client.

At this point Colin ran away screaming^W^W^W pointed out Havoc's
previous discussion about object paths not being object references, etc.
So here I am to try and solve this.

One hacky solution is for my client library to send the address of
itself over the bus along with a path.  *Very* hacky, but it would work.
As a string would be foul, so a new type for bus addresses would be
better.

Or allow this sort of operation in the DBus model, so clients and
servers can call each other happily, and think of some other way of
representing it.  Maybe expanding object path to include an address?

Or expand the bindings so that server-side methods have a way of getting
to the message which caused their execution (interestingly bound async
methods can do this already through the (albeit private) context
structure).

Any comments?

Ross
-- 
Ross Burton                                 mail: ross at burtonini.com
                                          jabber: ross at burtonini.com
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF