hp at redhat.com
Thu Mar 22 21:27:04 PDT 2007
Dafydd Harries wrote:
> I'll try to elaborate. The goal is to allow the OLPC activities to make D-Bus
> calls over the network, without having to understand how the D-Bus messages
> are transmitted.
This isn't clear to me still - D-Bus already is a way to make calls over
the network. So what's the new/different part... what are some examples
of "how the messages are transmitted" for example - what details
specifically are you trying to hide from the activities?
> Hence my service should act like a normal bus service,
> listening on a local unix socket, except that messages sent over that socket
> are sent to the network, and messages received over that socket have come over
> the network.
> When I receive a message on the local unix socket I need to
> - validate the sender field in the message header, or add one if it's not
> - extract the destination field in the message header, so I know where to
> send it to
By destination field you mean the field from
dbus_message_get_destination() containing a bus name? How would you do
routing based on that? What are two concrete examples of the "where"
that you would send to, maybe?
> Doing these things entail demarshalling the message, examining it, possibly
> modifying it, and marshalling it. As far as I can tell, this is not possible
> with the current libdbus API.
What you've described sounds exactly like what dbus-daemon does, and it
uses libdbus... basically the DBusConnection demarshals the message
stream from a socket (whether TCP or unix domain) and gives you
DBusMessage objects, which can be examined and modified; then you can
send the modified message objects over another DBusConnection associated
with a different socket (TCP or unix).
But, I have a feeling what you mean is not exactly what dbus-daemon
does, so I think I'm still confused ;-)
More information about the dbus