Hi Jeong:
>> 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.
[Martin], So I need to know what platform you mentioned. You know we can?t
discuss IoTivity without some specific platforms. Now we IoTivity has support
Tizen, Ubuntu, Android, and all of these OS provides the service to Monitor the
network status. I think we just need a OS abstraction layer abstract the call
back for each OS to call.
So as to whether to export the specific connectivity to apps, that depend on
how you design and view the IoTivity and IoTivity application. I think IoTviity
application should just be the pure user application, so we need to make it as
simple, as easy, as portable as possible. currently your design looks like put
the network/connectivity complication burden to the IoTivity application. That
makes the app complicated, and difficult to port.
As concept of layer of abstraction, IoTivity itself should be the application
layer and should not handle the transport layer. transport layer should be
handled by abstraction layer(together with specific OS transport layer service
or stack). Of course if you want to make IoTivity as well as the IoTivity
application as the part of system level services, that is also ok.
So as to select the connectivity, at most situation, I think we should let
IoTivity as well as the platform to pick the proper connectivity technology
according to the performance and connectivity status of the platform. If you
have some specific example that application must select the connectivity that
will help a lot. ?
>> 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.
[Martin] I think we just need IPv4 adapter. And define the OS abstraction layer
callback, so we can merge all the IPv4 adapters. ?
>> 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
[Martin] at linux and Tizen, using (NetworkManager and ConnMan) you also need
not the root permissions. ? and your current network monitor so has some
issues, you can?t decide the adapter is ready to connectivity just by
monitoring whether the IP is setup. I still think we need to have OS
abstraction layer and callback, we should use the network monitor service on
each platform. we should not do the same thing in IoTivity that already done in
specific OS or platform.
BTW, what your ?public? API means? It is POSIX API???
Thanks!
From: MyeongGi Jeong [mailto:[email protected]]
Sent: Thursday, February 05, 2015 0:00
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 myeong.jeong at samsung.com<mailto: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!
[cid:image001.gif at 01D0444B.15006DD0]
[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=0fb23a0626ef7dab1977be31c7870e43dbdc914173dfb188032aa89e99be1a3ead4b125b8cbc63175adb39b2255f42755296970253332b3707805447a154a46fcf878f9a26ce15a0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150209/52ed315c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 13168 bytes
Desc: image001.gif
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150209/52ed315c/attachment.gif>
