On quarta-feira, 3 de agosto de 2016 05:18:54 PDT ?? wrote: > Hi Thiago, > > We have few comments about your constrained implementation feature for > IoTivity. > > 1) Why we require this implementation separately now, when we have IoTivity > base already (both client and server together ) running on Arduino Mega > which has 128kB flash and 8kb RAM? > > -- Your proposal (constrained implementation) stack 84kB (client > or server not both) and 16kB RAM. l
Because we don't. The Arduino implementation has serious problems: * it's not a serious OS. Arduino is great for hobbyists who are getting started, but no one we've ever talked to or read research on uses it for real products. Arduinos are at most used in very early prototypes, and then the team moves on to a different OS and HW. * it's not a serious implementation: it lacks a lot of functionality. The numbers you quoted above haven't been current for a long time and, last I checked, it lacked the security support. * it's got serious problems with the shield firmware * its design is not very good for an RTOS that does other things. It takes over control of the OS and works in a main-loop style. RTOSes that need to do other things like control the actual device, keep connectivity up, etc., need a completely different design. * it calls malloc. Tiniest RTOSes don't have malloc. If you put it all together, you conclude that we need an implementation that works on a serious, modern RTOS, that has support for real hardware that our users would use for products, implements all of OCF (as applicable) and doesn't call malloc. Those failings remove the Arduino implementation as an option. > 2) IoTivity already has Rich (C++ + Base) and Lite stack (C-SDK) with multi > thread and single thread models, which are suitable for all platforms > depends on limitations of of binary size. How your proposal makes the c-sdk > version represented from now on? obsolete ? That's up to the project to make that determination. The creation of a constrained implementation does not immediately mean the C SDK is obsolete. In fact, I believe it won't be, if we consider bindings to other languages that wrap around the C SDK. Microsoft may have an interest in wrapping at that level for their .NET language offerings too. It may also be useful for small devices that still have a couple of MB of RAM and run a mainstream OS. For example, OpenWRT running on routers with an 8 MB (uncompressed) squashfs and 16 MB of RAM is a perfect target. But as a solution for very small devices (< 2 MB RAM), I believe the new implementation is much superior and the use of C SDK for this becomes obsolete. > 3) IoTivity already supports tiny platforms such as Tizen, Arduino and > compliable on Linux and Android. Why don't we port IoTivity to Zephyr? and > IoTivity also support BT,BLE transports which is not with new proposal.. See above for some reasons. I don't think you appreciate how difficult it is to port IoTivity for an RTOS. John Light made an attempt to reduce the malloc() clutter and he posted about it a while ago, but in the end he was unable to fully remove it and the implementation was still very far from target. Please don't say Tizen and Android are small. They are three orders of magnitude bigger than our targets here. There's absolutely no way to start comfortably an Android HAL and JVM with less than 256 MB of RAM. I don't know how far Samsung's efforts to make Tizen Micro small after Intel left the project, but I would be extremely surprised if you've reached a 16 MB target. Even then, that's 1000x bigger. > 4) Initially we proposed single thread model having separate files for lite > version of the stack but it was rejected by open source community. But now > we are coming back with same kind of solution. How we can proceed? This is > contradicting with decisions we have taken earlier. That's not the same. There were quality concerns with the implementation that was proposed, as it contained a lot of copy & pasted code across files. Maintenance would have been a problem. Besides, as was discussed at the time, if the only difference is the single- vs multi-thread, it's no choice at all: all we needed was a set of wrappers around the threading primitives. This is not about single vs multithreaded. The whole *design* changes to accommodate RTOSes. Zephyr doesn't use threads, it uses fibers. The new implementation doesn't take over control of the OS, but just works as an another service for things that the application needs doing. It also does away with a lot of the dynamism and abstractions for things that could conceivably happen, that IoTivity needs to support. And the malloc problem. > 5) By Introducing new source base, we are introducing unmanageable > maintenance interms of code, release, bug tracking, plug fest tracking, > spec compliance, SQA testing for release and create confusion for the > IoTivity developers etc. . Why we need to have this effort at all? First of all, I dispute that it's unmanageable. We believe it to be very manageable because the effort is bounded. The tiny implementation isn't meant to grow to all use-cases, but simply do the work that constrained implementations expect to do. If something needs a lot, it's no longer constrained and should use main IoTivity. Second, most of what you're saying was inevitable. IoTivity was never going to be the only implementation of the OCF protocol. In fact, this new implementation here is not the second, but the fourth implementation that we know of (Soletta's and St?phane's Copper-based one being second and third). We need to interoperate with other implementations and I think that having a second one under IoTivity's banners allows us to do that testing ourselves, validate one design against the other, the complexity of packet formats, impact of changes, etc. And third, we believe that the gains outweigh any increased complexity. We *need* an implementation for devices this small and we didn't have one until now. > 6) If we keep adding parallel stacks with IoTivity like constrained, more > constrained, tiny..etc , everyone will start writing their own code and > making a separate git. IoTivity itself meant to be a single open source for > OCF spec but not meant for OCF spec compliant stacks. I disagree. Nothing says that we need to work on one implementation only. How many, we get to decide. If someone comes later with another implementation that aims at targets different enough from our two, with different goals in mind, why not allow it? > 7) There is no discussion on this project as per new process. We have not > seen any wiki or discussion during dc_tg or any other meetings. Could you > give where the documents uploaded? The discussion is starting now. The code is just getting started, so we will provide more details as time goes by. Right now, the discussion is in the stage of "concept", where I am posting the idea that we're going after and seeking feedback. Since we already have a PoC, we can provide details on our implementation designs if people want to discuss that. Do you wish me to? IoTivity has no such thing as "dc_tg". You must be talking about an OCF task group, which is out of scope. OCF does not decide what goes in IoTivity and is not in the decision-making path. There's no need to pre-brief OCF. That said, I did pre-brief a lot of people during the June meeting and a presentation about what we were looking at was circulated. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
