Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 21 Jan 2020 21:15:01 +0100
From:   =?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek 
        <michal.lowas-rzechonek@silvair.com>
To:     linux-bluetooth@vger.kernel.org
Cc:     brian.gix@intel.com, inga.stotland@intel.com
Subject: Re: [RFC BlueZ 0/2] Fix types and names of beacon/import flags.
Message-ID: <20200121201501.v4ceigg5xngfvjb4@kynes>
Mail-Followup-To: linux-bluetooth@vger.kernel.org, brian.gix@intel.com,
        inga.stotland@intel.com
References: <20200109083855.16000-1-michal.lowas-rzechonek@silvair.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200109083855.16000-1-michal.lowas-rzechonek@silvair.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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 <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND