On Fri, 2019-09-27 at 17:25 +0000, Stotland, Inga wrote:
> Hi Brian,
>
> On Fri, 2019-09-27 at 15:50 +0000, Gix, Brian wrote:
> > On Fri, 2019-09-27 at 10:52 +0200, michal.lowas-rzechonek@xxxxxxxxxxx
> > wrote:
> > > Inga, Brian,
> > >
> > > Still, even if we add a method, the application is free *not* to
> > > implement it, since we agreed back in the day that calls to
> > > MessageReceived do not require a response, so any errors would be
> > > simply
> > > ignored by the daemon.
> >
> > This is not an option.
> >
> > A node does not get to decide which susbscriptions are "valid". If a
> > Virtual Address subscription is added to
> > a node, and then a message is sent to that virtua address, the App
> > needs to be able to receive it.
> >
> > Yes, any discrete message may be lost, but I don't think we have the
> > option of letting *all* virtual addressed
> > messages to an App to be ignored. If we add an App API, it will need
> > to be mandatory, which is why I am
> > against it.
> >
> > I strongly believe we need:
> >
> > 1. A single method for delivering (non dev key) received messages
> > 2. A method that does not require dictionary parsing
> >
> > How are we feeling about:
> > void MessageReceived(uint16 source, uint16 key_index,
> > array{byte} destination, array{byte} data)
> >
> >
> > Where destination length of:
> > 0 - Unicast address of element
> > 2 - Group Address
> > 16 - Variable Label
> >
> > I think this fulfills all of our requirements.
> >
>
> 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. Would these work like C++ overloading?
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?
>
> 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.
Configuration dictionaries can generally be ignored by simple Apps, so
Dictionary parsing is always optional for Attach() and
UpdateModelConfiguration(). However even simple Apps need to be able
to tell the difference between Unicast and Non-Unicast destinations
for receptions, because the rules for responding are generally different...
Which is why the current method has the simple boolean.
