[systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

April 25, 2017 9:54 AM, "David Herrmann" <dh.herrmann at gmail.com> wrote:

> Hi
> 
> On Tue, Apr 25, 2017 at 9:40 AM, David Härdeman <david at hardeman.nu> wrote:
> 
>> April 21, 2017 1:22 PM, "David Herrmann" <dh.herrmann at gmail.com> wrote:
>>> On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman <david at hardeman.nu> wrote:
>> 
>> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
>> On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman <david at hardeman.nu> wrote:
>> I'm implementing a server which creates an ObjectManager using the
>> sd-bus API and there seems to be some differences between how gdbus and
>> sd-bus implements the API.
>> 
>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>> exports objects /org/gnome/TestManager/fooX with interface
>> org.gnome.TestManager.Device.
>> 
>> Under sd-bus, if an object is removed, the following signal is
>> generated:
>> 
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>> object path "/org/gnome/TestManager/foo0"
>> array [
>> string "org.freedesktop.DBus.Peer"
>> string "org.freedesktop.DBus.Introspectable"
>> string "org.freedesktop.DBus.Properties"
>> string "org.freedesktop.DBus.ObjectManager"
>> string "org.gnome.TestManager.Device"
>> ]
>> 
>> If I implement the same simple server in gdbus, the signal is instead:
>> 
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>> object path "/org/gnome/TestManager/foo0"
>> array [
>> string "org.gnome.TestManager.Device"
>> ]
>> 
>> The corresponding signals are also generated when an object is added.
>> ....
>> Does the appended patch fix your issue?
>> (line-breaks might be screwed, sorry)
>> 
>> Haven't tried it yet, but just from reading the patch...it seems to do
>> the opposite of what I'd expect? I.e. add *more* interfaces?
>>> This change makes sure all objects have the built-in interfaces
>>> reported at all times. The GetManagedObjects() call didn't report them
>>> so far.
>> 
>> Quite the contrary? If you look at the output from dbus-monitor above, you'll see that it is sd-bus
>> that already *does* report all interfaces while gdbus doesnt?
> 
> No, it does not. sd-bus was inconsistent. See, there are 3 things
> involved in the Object-Manager:
> 
> Signal: InterfacesAdded
> Signal: InterfacesRemoved
> Call: GetManagedObjects
> 
> The first two signals are used to add and remove objects (and their
> respective interfaces) at runtime. The GetManagedObjects() call is
> used to bootstrap, that is, to get the initial set of objects (and
> their respective interfaces) when starting your application.
> 
> So far, sd-bus reported the builtin interfaces correctly via the
> signals, but did not return that information in the
> GetManagedObjects() call. My patch fixed this omission.
> The effect of this is that objects added/removed at runtime work fine,
> but if an object was there already when your application starts, then
> it will never be removed, since gdbus will see an interface-count
> mismatch (as you observed above).
> 
> Hence, the patch I provided fixes how sd-bus provides this
> information. It does *not* change any policy.

Oh, I see. Thanks. I'll try the patch ASAP.

Regards,
David