John, Regarding target device size for the existing code base; all that I can say is 'yes'
Regarding the difference in position; you should be watching this discussion. If you want to interop with iotvity, our obligations may become your obligations including tracking routes for message routing. This would include keeping a RMInfo DB. This increases state load on clients and servers to maintain the mesh information. I would have liked this to stay optional until we had time to evaluate the architecture in the real world. The design says that the details of the congestion control is in the code. The memory overhead is not even considered. Pat > -----Original Message----- > From: Light, John J > Sent: Wednesday, September 23, 2015 5:41 PM > To: Macieira, Thiago; Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org > Subject: RE: [dev] Discovery mechanism broken > > I will interject the smallest of comments here. > > The current IoTivity code base will never be used on the smallest of devices. > It > may be useful to consider how small it can be, but the answer will be "not > very > small". So the difference between your positions may not be all that > important. > > I am working on a tiny OIC server, and I guarantee you it won't look anything > like IoTivity. I'm sure there will be others. > > John Light > > > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > Sent: Wednesday, September 23, 2015 2:35 PM > To: Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Discovery mechanism broken > > 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 > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
