[PATCH] Add a parameterised gtype for structs

[Rob Taylor]

[mm, forgot to reply to list.. damn mornings... ]

Havoc Pennington wrote:
> Ideally we could find a way to use the code in
> dbus-marshal-recursive-util.c to also test the glib stuff. It exports a
> function already (grep for generate_bodies) that returns all its test
> cases as raw data; if we could use that (or export some slightly
> different function) then the glib test suite could just get each test
> case, round-trip it through the glib bindings, and see if it gets back
> the same bytes as the original test case. Really this would be a pretty
> airtight way to test any binding.

That's a very good idea, I think one thing we discussed with splitting
out the bindings was a unified way to unit test each binding, this seems
a good way of going about it.

> On the bigger picture of the patch - I think we had a discussion about
> how to do structs a while back? Any writeup of why this patch does it in
> this way vs. others, general notes on the approach, etc.?

Well, as I saw it, there were two options for actually making the
bindings capable of marshalling every signature:
1) produce a true bijection from the glib type system to the dbus type
system
or
2) modify all marshalling recursion to also simultaneously descend the
dbus signature and marshal according to the signature.

Now obviously the python and perl bindings use 2), as its more natural
for those languages to say how something should appear on the wire than
force users to do odd things to be strictly typed.

However for glib, strict typing is completely natural, so 1) is the more
obvious choice. 2) would also have meant that several interfaces would
have to have changed (g_proxy_call, g_proxy_add_signal, etc), and that
we'd also have to store property and signal type information in
DBusGObjectInfo. TBH, it just seemed alien to the current modus operandi ;)

Another option that I quickly discarded due to its foul nature ;) was to
modify all of the dbus-gsignature code so that it could also follow data
as well as the type in order to discover signature for structs as they
existed before this patch, but not only is this horrible, as I'm sure
you'll agree, it also doesn't help for the cases where, say an array is
empty.


> Also, I asked Colin if he would take a high-level look at it.

That would be brilliant - it was slightly scary doing this without his
input! ;)


Thanks,
Rob Taylor