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?
[1] https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties
Each property (or the parent interface) must be annotated with the
org.freedesktop.DBus.Property.EmitsChangedSignal annotation to
convey this (usually the default value true is sufficient meaning
that the annotation does not need to be used). See the section
called “Introspection Data Format” for details on this annotation.
[2] https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format
org.freedesktop.DBus.Property.EmitsChangedSignal:
true,invalidates,const,false
If set to false, the
org.freedesktop.DBus.Properties.PropertiesChanged signal, see the
section called “org.freedesktop.DBus.Properties” is not guaranteed
to be emitted if the property changes.
If set to const the property never changes value during the lifetime
of the object it belongs to, and hence the signal is never emitted
for it.
If set to invalidates the signal is emitted but the value is not
included in the signal.
If set to true the signal is emitted with the value included.
The value for the annotation defaults to true if the enclosing
interface element does not specify the annotation. Otherwise it
defaults to the value specified in the enclosing interface element.
This annotation is intended to be used by code generators to
implement client-side caching of property values. For all properties
for which the annotation is set to const, invalidates or true the
client may unconditionally cache the values as the properties don't
change or notifications are generated for them if they do.
Michał Lowas-Rzechonek (2):
mesh: Rename IVUpdate import flag to IvUpdate
mesh: Change BeaconFlags property type to a dict
doc/mesh-api.txt | 20 +++++++++++++++-----
mesh/mesh.c | 2 +-
mesh/node.c | 13 +++++++++++--
3 files changed, 27 insertions(+), 8 deletions(-)
--
2.19.1
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?
--
Michał Lowas-Rzechonek <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
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.
Thanks,
Inga
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
Brian, Inga,
On 01/22, Gix, Brian wrote:
> Signal Emissions are Information Leaks
No, they aren't. Flags and IV Index value is public information, sent in
open text over the air in Secure Network Beacons.
> 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
Yeah, and you get the same info from listening to beacons. I would just
like to make it slightly easier to listen to locally. At the moment one
needs to wait for the beacon to be transmitted.
Anyway: what's your opinion about the proposed API modifications (IvUpdate
rename and BeaconFlags type change)?
--
Michał Lowas-Rzechonek <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND