[systemd-devel] sd-bus vs glib object path node hierarchy

[Lennart Poettering]

On Tue, 16.06.15 22:54, Krzesimir Nowak (krzesimir at endocode.com) wrote:

> 16 cze 2015 6:09 PM "Lennart Poettering" <lennart at poettering.net>
> napisał(a):
> >
> > On Tue, 16.06.15 15:51, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:
> >
> > > Hi,
> > >
> > > I have noticed that glib vs sd-bus have different hierarchy in terms
> > > of how objects are stacked. I don't have any argument why one or the
> > > other one would be better but I was wondering what the reason for this
> > > difference.
> > >
> > > "/com/a/b" registered with sd_bus_add_object_vtable
> > > Introspection:
> > > └─/com/a/b
> > >
> > > "/com/a/b" registered with glib
> > > Introspection:
> > > └─/com
> > >   └─/com/a
> > >     └─/com/a/b
> >
> > Yeah, the spec says nothing about this. It's not clear whether
> > "middle" nodes should be synthesized or not for cases like this. I
> > decided to keep things minimal for sd-bus, and I think we should stay
> > with that unless this turns out to be a real problem for
> > something. Note though that the nodes in between actually are
> > accessible if you use their path explicitly, they just aren't
> > announced in the introspection, that's all.
> >
> > But maybe Simon has an opinion on this? Simon?
> 
> That reminds me of a bug (or not-a-bug) in go-dbus [1] - it also generates
> flat hierarchy. This is a problem for tools like d-feet - they fail to
> introspect services with flat hierarchy. Of course, it might be a bug in
> d-feet itself.
> 
> [1] https://github.com/godbus/dbus/issues/14

Unless I misunderstand this sd-bus and go-dbus actually work very
differently here: sd-bus actually synthesizes an object and suppresses
it in the introspection. go-dbus doesn't even synthesize it. That
means that if d-feet asks the intermediary objects on an sd-bus server
all is good even if the service will never announce it voluntarily...

I also just verified that d-feet works fine with sd-bus services.

Lennart

-- 
Lennart Poettering, Red Hat