On Friday 20 March 2015 11:00:43 Kesavan, Vijay S wrote: > Thiago, Hi Vijay
> With regards to your comments, perhaps it will help clarifying some of the > initial goals of CA. CA, which sits below the resource model layer, is > intended to: Indeed, clarification seems to be in order. Is there any list of requirements or use-cases that CA is trying to solve? It would help incredibly if this were documented either on the wiki or in a JIRA ticket. > 1. support and manage multiple adaptors types - Ethernet, > WiFi, BT, BLE initially (as opposed to single IP adaptor support that > currently exists in master branch); Sounds like a misfeature to split Ethernet and WiFi. Everyone I've talked to for the past two months has been saying the distinction is artificial and creates additional complexity that isn't necessary. See also John's email saying it's neither necessary nor sufficient. This distinction should go away and we should have "IP" only. In addition: - John suggested having an option for "IP dual stack", one for IPv4 only and one for IPv6 only. I disagree, especially after the discussion with St?phane. It should be "IP" only and the stack auto-selects the most appropriate. - BT and BLE should refer to the OIC profile over BT, not for OIC-over-IP- over-Bluetooth. > 2. abstract the resource model from the > transport protocol so that if CoAP is replaced by a different protocol the > resource layer should not change; Agreed, that is important. That is in fact necessary for the OIC profile for Bluetooth, since it's not IP-based at all, so CoAP there makes no sense. We may be able to use some of the payload format, but that's about it. > 3. support multiple adaptors of the same type Agreed, that's mandatory. > The current CA code mainly focusses on item 1, some limited support for 2, > and no support for 3. > > The current APIs only support one adaptor of each adaptor type, a starting > step for APIs as well as implementation, and not a long term solution. It > should be noted that there are no current plans for CA to have "smarts" to > know that resources are reachable via multiple adaptors and manage > selection/switching between adaptors. For this reason, and also because > existing Iotivity services asked that the adaptor type be exposed, current > APIs include adaptor-type information. When you say "no current plans", are you including "no work expected before 1.0"? As long as CA is not part of the IoTivity API that users can use, we can fix it later. Otherwise, it's a fatal flaw and blocks 1.0. Why did the IoTivity services require the adaptor type? That's totally surprising to me. Given all of this discussion... sorry to be blunt, but do we need CA at all? It seems to be going in the wrong direction. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
