Unix FD Passing

[Simon McVittie]

On Mon, 04 May 2009 at 19:44:41 +0200, Lennart Poettering wrote:
> On Mon, 04.05.09 16:53, Alp Toker (alp at atoker.com) wrote:
> > Thanks for paying attention to this. ndesk-dbus is actively using 'f'
> > for 32 bit single precision floating point values and dbus-java and
> > dbus-python support it as well now to some extent too I believe.
> 
> Uh. Could you please post this upstream to the spec, then? If it's
> that well accepted then this should really be added to the spec!

FYI, the extent of float32 support in dbus-python is that the C part contains
#ifdef'd code for it at Alp's urging; it should work, but has never been
compiled, let alone tested. So, don't consider me to be part of the float32
implementor cabal :-)

I seem to remember someone benchmarked sending messages with arrays of 32- and
64-bit floats and was unable to find a performance difference, but I can't
find a URL.

Ryan Lortie's data-model/signature extensions in GVariant are much more
interesting, IMO, if anyone's putting in the effort to get feature negotiation
in the spec.

If I remember correctly, in Ryan's extensions, mx is "maybe x", i.e. either a
value of type x or a nil value that is distinct from any x, and () (the empty
struct, a type with only one possible value) is explicitly supported. There
is also a concept of wildcards: a* is any array; a? is an array of any basic
type (any type allowed to be a key in a dictionary); a{?*} is any valid
dictionary; and so on.

I believe mx has its own wire-protocol format, and () has a wire-protocol
format ("pad to 8 bytes then serialize nothing", probably, since it's just the
removal of a restriction in the D-Bus spec).

I'm not sure whether the wildcards have a wire-protocol format, or whether
their only use is to describe equivalence classes of signatures.

It would probably make sense for all of these extensions that are deemed to
be desirable to be implemented as a single feature (e.g. "data model v2"
could be the feature that indicates support for maybe types, empty structs and
float32).

Unix socket passing has to remain orthogonal, because it needs libc/kernel
support too.

I don't think released versions of any D-Bus binding/implementation should
support types not described in the specification - the alphabet is quite a
flat namespace - and as noted by the Windows people wanting to reserve win:,
all the possible address types and their semantics ought to be described in
the specification too. As I've said in the GVariant thread on gtk-devel-list,
I think GVariant's type extensions should be removed or #if 0'd if it's merged
into GLib before those types are supported by the D-Bus specification.

(If I remember correctly, ndesk-dbus used to #ifdef its float32 extension,
off by default?)

    Simon