[PATCH 0/3] CPU frequency scaling addon

[Richard Hughes]

On Mon, 2006-08-14 at 22:34 +0200, Holger Macht wrote:
> > I'm guessing the addon needs to return an array of strings, rather than
> > a variable message length list of strings. I know changing the message
> > format depending on the number of returned values breaks the dbus-glib
> > bindings for me, and I'm guessing the python bindings the same.
> 
> I don't really understand that. Can you please elaborate a bit why this
> should break any bindings?

In dbus-glib, you don't take the message apart manually, you treat it as
a blob, e.g.:

dbus_g_proxy_call (manager->priv->proxy, "OneMethod", &error,
G_TYPE_INVALID, G_TYPE_STRING, &foo, G_TYPE_STRING, &bar,
G_TYPE_INVALID);

so you can *only* call a method with a 'in:ss' 'out:void' structure with
this lump of code.

This means any method that can have a variable type really messes up the
glib code as you don't know how many G_TYPE_STRING's to expect.

I don't know for sure, but I'm guessing having a variable message
structure breaks introspection too.

> > 
> > Patch (attached) on top of your patch attached fixes the issue, making
> > the return type 'as' which matches most of the other HAL methods.
> 
> Ok, I will integrate this patch into the next patch I'm sending as soon as
> I understand that it is needed. At the moment, I don't have a concrete
> preference for any of the two methods ;-)

Brilliant, thanks.

Richard.