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
