Emit interface added signal

[Patrick Williams]

On Thu, Mar 18, 2021 at 04:03:21PM +0530, Ratan Gupta wrote:

> Proposal: Don't emit the interface added signal by the D-bus service if 
> we are restoring the D-Bus objects from file system.
> 
> Do we see any concern here? or any other way to fix the above issue?

Yes, this is pretty dangerous.  If you do this, mapper will not know
about your objects and they will not show up in queries.  This is
certainly not what you want.  (Mapper will delete your objects from its
cache when the service exits, and not know that you have new ones
because it did not get the signal.)

This isn't just about mapper though.  Anytime you do not emit the
signals, you then require applications to poll your service for
knowledge of your objects.

In general, you should not work around an issue in one application
(bmcweb in this case) by changing your dbus behavior.  This isn't the
first time that I've seen a similar request.

Having said this, there is one option for you.  This is completely valid,
and done by other dbus services we have, and arguably more correct than
what it sounds like you're currently doing.

   - Defer the service name registration until just before entering your
     dbus processing loop.

   - Create your restored dbus objects before this service name
     registration and use the `emitSignal=false` argument to prevent
     the signal from being emitted.

This pattern is your way of indicating "these aren't new dynamic
objects, but objects I'm creating at the beginning of my service."
When mapper sees the NameOwnerChanged signal, it will query your service
for objects and add them to its cache.  `bmcweb` won't see the
ObjectManager.InterfacesAdded signals for these static / restored
objects, but it will see them for new / dynamic objects.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210318/0660ce0f/attachment.sig>