demarshalling messages

[Havoc Pennington]

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
>    there
>  - 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 ;-)

Havoc