Re: mesh: org.bluez.mesh.Element.MessageReceived method does not provide destination address

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

Hi Michał, Inga,

On Fri, 2019-09-27 at 10:52 +0200, michal.lowas-rzechonek@silvair.com wrote:
> Inga, Brian,
> 
> On 09/26, Stotland, Inga wrote:
> > While I am still in favor of two distinct methods (given choice, I'd
> > always go with self-explanatory API)
> 
> So do I.
> 
> > I vote against u16 destination field since there is no reason to
> > create address space collision even though the chances are small.
> > 
> > A single method "MessageReceived" method can be modified to include a
> > subscription parameter as:
> > 1) a dictionary with keys "Group" and "Label" (self explanatory if a
> > bit cumbersome).
> 
> If we really need to avoid two separate methods, I think it would be a
> bit cleaner to pass this parameter as a D-Bus variant of (u16,
> array[16]) instead of a dictionary.

Here is an interesting idea...

Is it possible to use a variable sized array for the address?

0 octets -- Destination is the Unicast address
2 octets -- Destination is a network byte ordere (Big Endian) u16
16 octets -- Destination is a 128bit Virtual label

The caveat here is that there would be two variable octet arrays in the message,
but from a D-Bus efficiency standpoint, might be the best we are going to do.

>