On Wednesday 23 September 2015 14:26:08 Lankswert, Patrick wrote: > 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.
Neither of which is a compliance issue. If I send an X-Foo header in HTTP in my server and your browser interprets it differently than what I intended, RFC 2616 gets to wash its hands. Extra options must be supported in order for manufacturers to be able to extend functionality. > 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". I agree in principle: the feature must not cause undue overhead in the smallest of devices. If it does, the feature has a design flaw. For this feature to be useful, all devices must be able to understand it. So the questions are: - do you consider the overhead to be too much? If so, it's a design flaw and needs to be addressed. - do you consider the implementation to be faulty and have destabilised the core? If so, it also needs to be addressed by refactoring. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
