Re: [RFC BlueZ 0/2] Fix types and names of beacon/import flags.

["Gix, Brian" <brian.gix@intel.com>]

Hi Inga & Michał,

On Wed, 2020-01-22 at 00:44 +0000, Stotland, Inga wrote:
> Hi Michal,
> 
> On Tue, 2020-01-21 at 21:15 +0100, Michał Lowas-Rzechonek wrote:
> > Hi Brian, Inga,
> > 
> > On 01/09, Michał Lowas-Rzechonek wrote:
> > > This patchset aims to make the API a bit more consistent.
> > > 
> > > Side question: at the moment none of the node properties emit
> > > PropertiesChanged signal. I think this violates D-Bus spec, since all
> > > properties are assumed to emit these signals by default [1] [2].
> > > 
> > > Unfortunately, at the moment ELL does not support "EmitsChangedSignal"
> > > annotation, so I'd like to add this to ELL, annotate node
> > > properties with:
> > >     - Features: const
> > >     - Beacon: true
> > >     - BeaconFlags: true
> > >     - IvIndex: true
> > >     - SecondsSinceLastHeard: false (for performance reasons)
> > >     - Addresses: const
> > > 
> > > And also emit PropertiesChanged where required.
> > > 
> > > Thoughts?
> > 
> > Any comments about this idea, or should I just go ahead and send a
> > patch?
> > 
> 
> I think this is a good idea. I agree with the proposed node properties
> annotations.


I honestly would like to never emit any signals for Mesh, and if it is legally possible for
SecondsSinceLastHeard (a property which literally changes value every second) then I hope it is possible and
legal to never emit anything....   They should be polled only.

Unless someone can come up with a use case that requires signals to notify a specific piece of information has
changed, Signal Emissions are Information Leaks that provide no benefit...  they are sent globally to anyone on
the DBus, and signals to anyone who may be eavesdropping that *something* is happening, even if the details of
the change are "hidden".

Are there any use cases that necessitate DBus Signals in Mesh?

--Brian