Hi Michał,
Can you submit a patch set with these agreed changes, that includes:
* doc/mesh-api.txt changes
* Source code changes
* test/test-mesh changes that conform to new API
On 30-Sep-2019 Michał 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.
