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:   Mon, 30 Sep 2019 09:18:03 +0200
From:   "michal.lowas-rzechonek@silvair.com" 
        <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "Stotland, Inga" <inga.stotland@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: mesh: org.bluez.mesh.Element.MessageReceived method does not
 provide destination address
Message-ID: <20190930071803.nvp3ema26ynuiwz3@mlowasrzechonek2133>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "Stotland, Inga" <inga.stotland@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <20190830184301.zd3zaqrw7mv6r252@kynes>
 <20190918085239.xhahxoeqjkcrk3bl@mlowasrzechonek2133>
 <3c5858c94b3e08a61c5ff8493f9b00f5f77d0aac.camel@intel.com>
 <4b57242b15ccb44ac123858ce7bdf6e0e526b3e0.camel@intel.com>
 <a0442c7485fef2bfde9bc52283a5c9dfc0b43515.camel@intel.com>
 <20190927085208.sxy2x5656ci3opo6@mlowasrzechonek2133>
 <01c84f55db98fbcc2790d11fd6090589881c36cf.camel@intel.com>
 <856d4e6bfdbe84b7b7ac3742ebede263c7801346.camel@intel.com>
 <86e707237937cfb5c4e8fea8e96924f4590ab0a3.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <86e707237937cfb5c4e8fea8e96924f4590ab0a3.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Brian, Inga,

On 09/27, Gix, Brian wrote:
> > For a single MessageReceived() method, the cleanest way is to have the
> > subscription address parameter as a variant (suggested by Michal) or as
> > a dictionary.
> > An array introduces an extra consideration of byte ordering for group
> > addresses.
> 
> If variants are easy to sort in scripting languages like python3, than I
> suppose I could live with this.

Last time I checked, it was C that had issues with  any type of
'dynamic' typing, so I wouldn't worry about client languages. Handling
D-Bus variants in python is trivial.

> Or is this still a two step process of:
> 1. Determining the u16 vs u128
> 1.1 unmarshalling the correct type...
> 
> What would the signature of the method look like?

Something like this:

	void MessageReceived(uint16 source, uint16 key_index,
					 variant destination, array{byte} data)

and on the Python side, the handling would look somewhat like this
(since Python doesn't do overloading, at all):

class ElementInterface:
	def MessageReceived(source, key_index, destination, data):
	    if type(destination) == dbus.types.UINT16:
	        group_destination = destination
	    elif type(destination) == dbus.types.ARRAY:
	        virtual_destination = uuid.UUID(destination)
	    else:
	        raise DBusError('Unrecoenized destination type')

> > What I mostly about is that the represenation of the subscription
> > address in the MessageReceived() method corresponds to the
> > representation in the configuration dictionaries for the Attach() and
> > UpdateModelConfiguration() methods.

Agreed.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND