Unix FD Passing

[Lennart Poettering]

On Wed, 20.05.09 16:55, Havoc Pennington (hp at pobox.com) wrote:

> I'm wondering a bit if the user of libdbus should have to enable
> feature extensions ... that would get pretty gross in the long term.
> But the problem is that if libdbus supports fds, but the binding
> doesn't, then in effect we don't support fds - but we're advertising
> that we do.

I don't think this is really a problem.

If a binding doesn't do unix fd it should never be tempted to generate
a message with unix fds. Hence it doesn't matter if the connection it
is using has negotiated it or not.

If a binding doesn't do unix fd it should never be tempted to expose
an interface that needs unix fds and hence never expect a message with
unix fds. And hence again, it doesn't mater if the connection it is
using has negotiated it or not.

The exception are the tools that try to genericly handle all kinds of
messages. i.e. d-feet, dbus-monitor and such. And they should simply
make sure to fail cleanly on messages they cannot produce or cannot
parse.

I really don't think that nego between libdbus and the client/binding
would be a good choice. That complicates things, for the single
benefit of simplifiying writing clients that want to handle generic
messages. Also, you could even go one step further then: i.e. if
libdbus and the binding need to negotiate, then also the binding and
the application itself need to negotiate. And that would be awful.

I think the best option is to document that clients/bindings should
*never* try to genericly handle types they don't fully
understand. Let's just outlaw that! 

In fact that should probably have been documented anyway since release
1. This is the only option to make future extensions of the protocol
easy and not completely ugly.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4