[patch] generate marshallers and metadata from dbus-glib-tool
kuliniew at purdue.edu
Fri Nov 19 07:48:04 PST 2004
On Fri, Nov 19, 2004 at 10:10:00AM -0500, Havoc Pennington wrote:
> On Thu, 2004-11-18 at 15:32 -0500, Paul Kuliniewicz wrote:
> > * Stop sorting the parameter list based on argument direction.
> > * First "parameter" is the return value. If it returns void, type it
> > DBUS_TYPE_NIL.
> I think the ordering sensitivity should be kept on the binding level
> (dbus-glib) rather than in dbus; the ordering stuff would just be to
> adapt to non-native-dbus functions basically.
I was referring to this bit of dbus-gidl.c:
method_info_add_arg (MethodInfo *info,
info->args = g_slist_append (info->args, arg);
/* Keep "in" args sorted before "out" and otherwise maintain
* stable order (g_slist_sort is stable, at least in sufficiently
* new glib)
info->args = g_slist_sort (info->args, args_sort_by_direction);
> The default if there's no override I would say should be:
> - there are never out params as C function return values,
> the C function always returns bool for error/no-error
> - out params are always after all in params
> - there are no inout params
> These are native dbus semantics. So if we autogenerate a C function it
> would look like this.
I'm talking about describing the functions that are being wrapped, not
any functions that are being generated. The functions being generated
by dbus-gidl-tool have a fixed signature that does behave that way.
It strikes me as counterintuitive to force calling semantics alien to
GLib conventions on a GObject-derived object just because it's being
exposed via D-BUS.
> However, we might want a facility on the server side to take an existing
> C function that doesn't follow these rules and expose it via dbus.
Which is what is essentially being done now, unless I'm misunderstanding
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://freedesktop.org/pipermail/dbus/attachments/20041119/cfe14beb/attachment.pgp
More information about the dbus