Hi Michał, Inga, On Fri, 2019-09-27 at 10:52 +0200, michal.lowas-rzechonek@xxxxxxxxxxx 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. >
