Hi, On Wed, 2019-09-04 at 13:26 -0700, Gix, Brian wrote: > On Wed, 2019-09-04 at 21:48 +0200, Michał Lowas-Rzechonek wrote: > > On 09/04, Michał Lowas-Rzechonek wrote: > > > The two examples I provided are *not* violating the spec in any > > > way. > > > For the record: > > > - a combined server/client sitting on element 1 that receives > > > onoff > > > messages and, depending on the destination address, sends a > > > different > > > onoff messages to a "regular" onoff server sitting on element > > > 0, > > > allowing efficient control over switching scenes involving > > > large > > > number of nodes This sounds like something a vendor model mechanism should handle: the "mapping" should be understood on both ends: client and server. > > > - a model that acts as a IPv6 gateway and directly maps virtual > > > addresses to IPv6 addresses of nodes living on the other side > > > of the > > > gateway > > > > Another one about virtual addresses: > > > > In CANOpen, there is a concept of a "Protocol Data Object" [1]. > > Basically, the idea is to pack many pieces of information into a > > preconfigured format (down to single bits, because CAN frames are > > even > > shorter than mesh ones) - this is known as "PDO Mapping Parameters" > > - > > then send such payloads to a well-known group address. > > > > In static configurations, this allows to decrease the number (and > > size) > > of packets sent by sensor nodes. > > > > Since PDO payloads are *not* self-describing (unlike mesh sensor > > messages), the receiving party must be aware of the mapping in > > order to > > parse the data. > > > > In CANOpen, format is determined by the address - in mesh, it could > > very > > well be a virtual label. > > > > [1] https://www.can-cia.org/can-knowledge/canopen/pdo-protocol/ > > > > I think that this is an interesting use of Virtual Addresses, and in > addition to this, Mesh Virtual Addresses > have been suggested as a way of addressing IPv6 addressing as > well... However: > > 1. There is already a way something like this could be used > already: A model could be created that gets > subscribed to the Virtual Addresses that require handling by the > node. > > 2. If such a system proves to be widely requested, daemon support > could be added (perhaps under a different > DBus interface) for either or both of IPv6 and "CANOpen". > > In any case the ability to create simple mesh Apps with minimal > complexity remains intact, and as an added > bonus, the Open Source community (not to mention the Bluetooth Mesh > Working Group and larger SIG) can weigh in > on the preferred methodologies. > My feeling is that the API should be geared towards common case scenarios (i.e., defined models and such). If there is a behavior that absolutely cannot be addressed with the current API (and use of vendor models), then it has to be changed/augmented. As such, I still don't see a compelling reason to do so.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
