Hello This email serves as the official request and the beginning of a discussion for a new Git repository in iotivity.org to contain a new implementation of the OCF protocol, designed for constrained devices.
If there are no objections, we'd like to upload the code one week from today. Some FAQ: Q: why a separate repository? This is a completely different codebase. It shares no code with main IoTivity, aside from a TinyDTLS copy, which will be removed once IoTivity de-forks its copy too. It targets OSes that the main IoTivity does currently not, and makes assumptions that the main IoTivity cannot. We're asking for a repository called "iotivity-tiny.git", but we'll accept other suggestions too. Q: why a new implementation, instead of the IoTivity C SDK? We found it a lot easier to just write something from scratch than to clean up resources/csdk to work on constrained devices. The new implementation is designed for such devices, which often have different assumptions and requirements than mainstream OSes. For example, this new code has absolutely no calls to malloc(), but as a counterpoint, it has many decisions and limitations decided at compile-time. The team was able to take those "liberties" with the code because there were no dependencies on top. The API is different from IoTivity's and is not meant to be a drop-in replacement (it uses similar concepts, though). Q: is it the same implementation as Soletta's? No, it's not and this implementation does not depend on Soletta either. It requires very few things from the OS itself, like access to an UDP socket as well as a time-keeping mechanism. Q: what OSes does it support? Currently, it supports Zephyr (https://zephyrproject.org) primarily. It can also be compiled on Linux, but that should be seen as a tool to ease development, rather than a real target. Porting it to different OSes should be possible. We're considering whether to port to Contiki and/or RIoT, but we have no plans at this moment to do so. We welcome contributions in that area. Q: what is its licence? Same as IoTivity's, it will be released under Apache Licence version 2. It contains some third-party code with more permissive licence than that (e.g., TinyDTLS). Q: what will its governance be? If accepted as an IoTivity code, it will be governed just like the main IoTivity implementation, via Gerrit and by tracking bugs in JIRA. We are proposing: Maintainer: Kishen Maloor Sub-maintainers: Otavio Pontes, Flavio Ceolin Architect: Thiago Macieira Q: how big is the implementation? Last time we measured, we were looking at roughly 84 kB of flash required for either a client or server implementation (not both) and about 16 kB of RAM. These figures include TinyDTLS, but do not include the OS itself. Q: does it support hardware crypto? How about TCP/IP offloading? Offloading of the actual network is the responsibility of the OS and should "just work". Off-loading of CoAP or crypto is an area to be researched and we'll likely investigate at least the crypto side, but haven't done so yet. Q: what does it require from the OS? Does it require TCP? - timekeeping (clock) - a random number generator - IP / UDP connectivity w/ multicasting no TCP required; we haven't investigated Bluetooth yet - persistant storage Q: what language is it written in? Pure C. Q: what OCF features does it support? - OCF client, server or intermediary roles - OCF discovery, observe, slow resources, reliability using CON requests - OCF Security (DTLS and ACLs; "just works" OTM; 128-bit pairwise credentials) Currently tracking the main IoTivity 1.1 implementation, so it should match OIC 1.1 spec. Q: will it provide the same guarantees as main IoTivity on passing OCF certification? Yes, that's our intention: we'll make sure that the implementation passes certification. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
