Jaehong Jo I have no plans to eliminate the CA API, but I see it as a barrier to creating the effective IoTivity stack that we all want. I will describe one example of the difficulties the CA ?API? presents. One aspect of the IPv6 plumbing involved unifying the transmission of network addressing information throughout the stack. From the application developer?s perspective, there is one IoTivity stack, which starts at the C++ API and proceeds to the very bottom of the network adapters. To make this work better for her, we need to minimize the number of memory allocations and memory copies. I made a step in the direction of reducing the number of allocations and copies with the IPv6 plumbing work. There is now a single form of a network address used from the top to bottom of the stack. It is named OCDevAddr in the C++ code and RI layer, and it is named CAEndpoint_t in the RI and CA layers. OCDevAddr and CAEndpoint_t are defined identically, and the intention is that they remain identical. The best way to make them identical is to have a single definition of the important structure, but that is not possible in the current design. There is no way to define a structure that is used by C++, RI, and CA. A structure defined in the CA layer can be used in the RI and CA layers. A structure defined in the RI layer can be used in the C++ and RI layers. But there is no way to define a structure such as CAEndpoint_t/OCDevAddr that is used in all three layers. This artificial separation means that we must allocate and copy these structure at various point in processing, leading to lower performance and greater risk of misuse of the structures. This is one example of the cost of the unnecessary separation. A similar argument can be made for the payload data. A payload structure that can be used at all three layers would minimize the amount of allocation and copying in the stack, but that is not possible in the current design. Certainly the capabilities of the CA layer must be respected, but we must be able to optimize the product. One solution to the problem I have described would be to place RI include files in CA code, effectively breaking the CA ?API?. Then RI include files could define structures that are used throughout the stack. We must be able to reorganize and refactor the IoTivity stack to make it an effective competitor to competing solutions. I expect that we will find that maintaining the CA ?API? will become a significant barrier to competing effectively. John Light Intel OTC OIC Development
From: ??? [mailto:[email protected]] Sent: Thursday, July 23, 2015 5:44 AM To: Lankswert, Patrick; Kesavan, Vijay S; Light, John J; iotivity-dev at lists.iotivity.org Subject: RE: [dev] CAGetNetworkInformation() function does not work Pat, Vijay I say independence is not a structural separation. John said the CA APIs will disappear in the near future. CA layer abstracts the platforms and connectivity types to provide unified transport interface and RI layer manages resources regardless platforms and connectivity types. If two layers are used without interface, occurs tight coupling.
