structs, custom type
Havoc Pennington
hp@redhat.com
Wed Mar 10 15:18:36 PST 2004
Hi,
I forgot one of the main issues with structs, that they have no good
C/C++ binding without causing IPC type system to leak all over the
place.
What DCOP does here is say you have a struct Point { int x, int y}
they just do a custom type:
name = Point
binary data = serialized x, y
So the idea with dbus today was that if you have a complex datatype or
struct you'd simply specify a name like org.freedesktop.Point, specify
the format in the byte array of DBUS_TYPE_CUSTOM, and bindings would
have to be specifically aware of the complex datatype or allow an escape
hatch through to apps so apps could be specifically aware of it.
Otherwise you have to have a DAny/DVariant object that has all the same
unpacking iterators found on DBusMessage, so you can bind structs to
that in C. Or you need a static definition of each struct in your C.
Perhaps the right way to think about this problem is how to have a
standard way to (un)serialize a custom type.
One answer may be to replace CUSTOM with STRUCT, have a name tag with
STRUCT as with CUSTOM, and you can just put a byte array in the struct
if you want to use your own serialization format as with CUSTOM, or you
can use a series of dbus types as your serialization format if you want
to make it easy for others to unpack.
Anyway, should think about CUSTOM/STRUCT as a single problem. Also, I
don't think libdbus should have a structname<->format mapping, that
should be only in bindings.
A separate issue to consider - right now unions or variants would also
be done in bindings, by just handling multiple type signatures on a
struct or method. This is consistent with libdbus being a transport,
specifying _what_ was transported but not comparing it to a conceptual
global repository of types. There's no names-to-types mapping in the
dbus core. A variant or union type is saying "this name could refer to
these multiple types" and thus isn't needed if we lack that mapping.
More accurately, we've punted that mapping to the bindings.
Havoc
More information about the dbus
mailing list