[PATCH] Adding an argument to Sleeping signal

Phillip Susi psusi at cfl.rr.com
Mon Apr 4 13:29:56 PDT 2011


On 3/30/2011 1:16 PM, Richard Hughes wrote:
> The shim library was only really useful before we had GDBus, now it's
> a little redundant.

So should the shim library be removed, or does it still serve some
purpose, and so I should update that as well as the real dbus interface?

>>> I'm still not sure if it's a sensible thing to change the public DBus
>>> API at this stage, as other things are using the existing signals
>>> (notably, NetworkManager). David, Kay, any advice?
>>
>> Before you said:
>>
>>> I think breaking API now is okay. You have to define a
>>> I_KNOW_THE_API_IS_UNSTABLE define to use upower now anyway.
>>
>> Change your mind?
> 
> Perhaps. I'm not super keen on changing an interface used by loads of
> projects. I think a new signal name might be better. I've not made up
> my mind yet to be honest.

I do hate to change the interface used by loads of projects, but on the
other hand, this interface was inherited from g-p-m which did have the
argument, and so putting it back is really just correcting the mistake
of removing it during the migration.  As more time passes, that becomes
harder and harder to do.

If you don't want to add an argument to the signal, is it possible to
add it as an attribute instead?  Or would that introduce a race
condition between the attribute being updated, and the signal being
processed?



More information about the devkit-devel mailing list