[patch] generate marshallers and metadata from dbus-glib-tool

Paul Kuliniewicz 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:

void
method_info_add_arg (MethodInfo    *info,
                     ArgInfo       *arg)
{ 
  arg_info_ref (arg);
  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
you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://freedesktop.org/pipermail/dbus/attachments/20041119/cfe14beb/attachment.pgp


More information about the dbus mailing list