MJ,
Hi. I needed some clarification on your comments. Can you provided detail on the platforms that have differences between WiFi and Ethernet? I ask because on the surface I would think that those differences should be abstracted. You also said ?Currently Android BLE, Arduino BLE is supported in CA and Tizen BLE is available with private binaries?. What do you mean by private binaries? Does this mean that we cannot build these from source from the repository? Is so, is there a plan for these to be made public? Pat From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of MyeongGi Jeong Sent: Thursday, February 05, 2015 3:00 AM To: Xu, Martin; iotivity-dev at lists.iotivity.org Subject: Re: [dev] some comments on CA Dear Martin. Thank you for your comments. We also have the same opinion that design issues need to be handled via technical discussion or via mailing list than in gerrit. As gerrit is exclusive for code review, it should not be mixed with design discussions. It?s difficult to explain the design in the code review process for each reviewer. Anyway coming to your comments, please check our in-line comments for your comments. Please share us your opinions . Thanks. Best Regards. /** * @name MyeongGi Jeong * @office +82-31-279-9172 * @mobile +82-10-3328-1130 * @email <mailto:myeong.jeong at samsung.com> myeong.jeong at samsung.com */ ------- Original Message ------- Sender : Xu, Martin<martin.xu at intel.com <mailto:martin.xu at intel.com> > Date : 2015-02-05 07:27 (GMT+09:00) Title : [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. >> There are different kinds of applications which use IoTiviity and >> practically it's not possible to satisfy all the application requirements. And, almost platforms don't provide connectivity enable/disable APIs. Application can monitor the status of the connectivities. That means application can not decide the suitable connectiviy for each scenario whatever intelligence we put in our source. It depends on the status of the connecitivies of the device at that time. If the connectivity changes at runtime, then CA detect it and provide the information about it to RI layer ( It will propagate to Application, I guess ) Then the appllication can aware the status change about the connectivities. We think application should select the prefered connectivity for the scenario, and also provided the user interface(if required) to enable/disable connectivities. 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. >> Regarding the discrimination( as you said ) of ETH and WIFI, we have seen some of the APIs are different in logic between platforms. In-order to have proper open source maintenance, it is separated. 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. >> There are multiple ways to monitor network connectivity in platforms. Some are pub-sub model and some are polling. We designed CA monitoring model in such way that it should not require root permissions and also use public APIs. CA monitoring is designed to be totally platform dependent and loosely coupled with adapters which means, it can be modified easily. 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). >> This issue we are tracking already with the following JIRA issue. https://jira.iotivity.org/i#browse/IOT-256 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. >> As said, we want to use public APIs which are available for all platforms and not specific to any Bluetooth stack like bluez. And, we guess, many kinds of EDR device such as health-monitoring, didn't support PAN profile. In addition, PAN operation consumes much power better than serial socket communication. 5. So as to support BLE support, I will give out comments later. >> Currently Android BLE, Arduino BLE is supported in CA and Tizen BLE is available with private binaries. Thanks! <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=0fb23a0626ef7dab1977be31c7870e43dbdc914173dfb188032aa89e99be1a3e13d69ea60670f66e1fac5bf6c61543587bc8a6096cfbfc9f02e038c8d853bffbdb9fdddda33e82cbe4a391424e62fcf6cf878f9a26ce15a0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150205/37635d23/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150205/37635d23/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150205/37635d23/attachment.p7s>
