Martin - thank you for your comments. If you have not already done so, please log these comments in the CA code review at this link<https://gerrit.iotivity.org/gerrit/#/c/193> so that it can be tracked/addressed there.
--Vijay From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Xu, Martin Sent: Wednesday, February 04, 2015 2:27 PM To: iotivity-dev at lists.iotivity.org Cc: Subramaniam, Ravi Subject: [dev] some comments on CA Hi: I went through the CA code, and have some comments on the design of CA. I'd like to share with people here. In general, the design framework is fine to me and I am impressed that the CA can be finished and send to review in so limited time. But I still have some concerns on the current implementation. 1. According to layer abstraction and my understand of OIC standard. OIC should be the application level standard. So I am not sure export the specific connectivity technology to IoTivity application is the right direction. a. At many situation, application writer does not know what the connectivity can be used b. Even they know what connectivity can be used, the system connectivity status may kept changing, for example, some time user may use WiFi, but in order to save power, user may transfer to use BT, use phone as an example, what user do is just use system UI to close WiFi and open BT, or at some smart device, system will do that automatically. So I do not think the IoTivity application should take the burden to handle that. They should just need to care about what resource they want to access, so as to use which kind of connectivity to handle it. should be decided by IoTivity according to the system statues and user input. c. Even we assume that the connectivity will never change runtime, export the connectivity to IoTivity application will also make the application porting difficult. We can't make sure the application basing on WiFi can be run on platform run on BLE or other connectivity. d. So all in all the connectivity should transparent to IoTivity application. 2. I do not know why we need to discriminate Ethernet and WiFi. Both of them use IP network, and the operation is almost the same. You will find the code on ethernet and wifi adapter in CA branch is quite similar. If user want to use Ethernet or WiFi, user can just remove the Ethernet cable or close the Wifi device. IoTivity should handle that. 3. Besides, I am not sure current WiFi/Ethernet adapter operation is the right solution a. To different OS there are different way to handle the IP network devices statues, Normally Ubuntu/Fedora using Network Manager to report the device statuses, some are using ConnMan(Like Tizen and Yocoto build linux) to report the connect technology status. Even you do not want to use either way, you need to use RTNL implemented in Linux kernel to monitor the network devices statues(you can reference code in ConnMan about RTNL). And current CA implementation to check the IP setting statues to decide the whether some network device is active is has some issue, the ip address can be set without network connected, only when the carrier is detected by RTNL and the ip address include subnet gateway and so on is set up correctly, we then can say it is connected or online. Personally I prefer to use ConnMan(at Tizen exported through related CAPI) to monitory the status. b. Do we need to supports multi-ethernet? If the device is home gateway, it is quite possible it has several Ethernet devices at same time. But Currently implementation, only handle the first ethernet/WiFi device(Correct me if wrong). 4. Do we really need spend efforts to use rfcomm to make use of Bluetooth BR/EDR? We can just use Bluetooth PAN which provides IP support over Bluetooth(I.e. LACAP), comparable to Wireless LAN on a PC. Please refer http://bluez.sourceforge.net/contrib/HOWTO-PAN. We already use PAN to run current IoTivity code successfully. So using PAN we can take Bluetooth BR/EDR, WiFi, Ethernet as one type of OIC connectivity. 5. So as to support BLE support, I will give out comments later. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150205/5eb18f3c/attachment.html>
