RE: [PATCH BlueZ v2] doc: Initial Bluetooth Mesh API

From: "Gix, Brian" <brian.gix@intel.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Johan Hedberg <johan.hedberg@gmail.com>
Cc: "Stotland, Inga" <inga.stotland@intel.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	"Marcel Holtmann" <marcel@holtmann.org>
Subject: RE: [PATCH BlueZ v2] doc: Initial Bluetooth Mesh API
Date: Mon, 12 Nov 2018 16:05:06 +0000	[thread overview]
Message-ID: <DEBB0CAA2616974FAE35E4B560B9A4375C132AB0@ORSMSX103.amr.corp.intel.com> (raw)
In-Reply-To: <CABBYNZ+1RqUJm3c_mQjF0DNDy1GWTKRP-v-66VN1ihEpf6Y3iw@mail.gmail.com>

Hi Luiz, Johan,

> -----Original Message-----
> From: Luiz Augusto von Dentz [mailto:luiz.dentz@gmail.com]
> 
> Hi Johan,
> 
> On Mon, Nov 12, 2018 at 2:58 PM Johan Hedberg
> <johan.hedberg@gmail.com> wrote:
> >
> > Hi Luiz
> >
> > > On 12 Nov 2018, at 13.24, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > >
> > > It seems wrong  to me to have to send your own object as method
> > > argument, usually this sort of communication goes as a Signal but it
> > > seems the Element interface has no signal to be able to do something
> > > like that.
> >
> > The problem with signals is that they cannot return an error, and I do think
> we’d want to have the daemon return an error if it cannot send the given
> message. Also, by default signals are broadcast, and it feels a bit hawkish to
> do unicast destinations for them.
> 
> Well unicast signals is not a new thing, though we never used it that would be
> possible to do something like that, anyway D-Bus signals are subscription
> based which is the reason we haven't consider it to be problem to emit signal
> for Value changes in case of GATT attributes, that said the lack of error result
> could indeed be a problem but some of the errors are actually due to the
> checking object_path is valid?
> Other errors Im not sure, Ive assume if there is a response that would then
> call MessageReceived, but perhaps we want to validate the transmission
> itself, but I though that wasn't possible in BlueZ.

After a number of negotiations, we decided on:

* Methods on Element Object Paths for incoming messages  (from 
Mesh-->Daemon-->App) for Security and differentiation between destination
elements (an App can implement multiple elements). While we may have
been able to get Signals to work Securely, the delivery of incoming messages is
*always* to a *specific* element, and really shouldn't be using a broadcast mechanism.

* Using the App's element Object path as the param (App --> Daemon --> Mesh)
to specify the Source address.  This was done to minimize the unique ways of
referring to the Element

> 
> --
> Luiz Augusto von Dentz