Thiago, >From the purist point of view, there are two issues if non-standard options >are inserted. The first is obvious, the certification folks will be interested >that when A goes in the top of the stack that B goes over the wire. Adding >options complicates things and requires education of the certification folks. >The second is a little more subtle, if a device manufacturer uses the same >option since it is not reserved by a standard and the core framework gets >confused or worse over-writes the option then we have a problem.
That said, the tech-world is full of such issues that have been addressed many different ways. I like the routing manager functionality, I am just not sure that there should be *any* required overhead on the smallest devices. Please remember that run-time decision require an increase in code size. There seems to be a real tension between the folks who say "build it big and moore's law will catch up" and "build it small and look at all of the applications that you can get into". Regarding effort on standards versus non-standards efforts; that has been my question for some time. Pat > -----Original Message----- > From: Macieira, Thiago > Sent: Wednesday, September 23, 2015 4:42 PM > To: Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Discovery mechanism broken > > On Wednesday 23 September 2015 12:37:39 Lankswert, Patrick wrote: > > Thiago, > > > > One of my obligations is to deliver a specification compliant stack. > > The routing manager is not based on any standard that I am aware of. > > We are free to add anything to iotivity, but to meet the > > standards-based obligation, I need to be able to build a version of > > the core framework that adheres to the standard. Adding non-standard > > options from within the stack is a problem. > > Having extra options in the header does not mean non-compliant design. The > extra header means that the endpoint client could accept replies from a > routing > manager, but if no one deploys routing managers, nothing happens in addition > to the spec-mandated behaviour. > > > In the design discussions, it was said expressly that the routing > > manager features would be optional. So, what was promised was not > delivered. > > It is optional. It just happens to be a runtime decision, not a compile-time > one. > And the extra header option notwithstanding. > > > It looks like a number of new issues in the stack are a result of the > > routing manager feature which was not a required feature, but now > > threatens the delivery of v1.0. > > That's a separate aspect -- the fact that there is new code that destabilised > the > core. > > For that matter, I have to ask: why do we have so many non-spec features being > developed while we're short on resources to implement the spec ones? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center
