All,
I object strenuously to the definition of OCConnectivityType. I agree that it
needs to exist, and I agree with its placement in findResource and
getDeviceInfo APIs.
I believe OCConnectivityType should look like CAConnectivityType.
typedef enum
{
CA_ETHERNET = (1 << 0), /**< Ethernet Connection */
CA_WIFI = (1 << 1), /**< WIFI Connection */
CA_EDR = (1 << 2), /**< EDR Connection */
CA_LE = (1 << 3), /**< LE Connection */
} CAConnectivityType_t;
Here are my reasons for objecting:
? The current definition doesn?t allow any combination of adapters not
pre-defined by IoTivity. For example, what if I want to findResources on WiFi
and EDR? There is no way to specify it with the current definition.
? More generally, the current definition doesn?t supply any means of
creating combinations of adapters.
? The OC_ALL value is and always will be a moving target. It is
currently defined as including WiFi and Ethernet. At some future time it will
include others. This means that applications will change behavior just by
rebuilding with a more recent IoTivity library.
? The current definition supports a bug in CA that I assumed would be
fixed because it is so egregious. In OCDoResource, multicast is only performed
if the value of the connectivity type is OC_ALL. If I pick any other value, I
multicast is not performed so no discovery occurs. For instance, if I pick
Ethernet to findResource, no multicast is performed. Multicast discovery
should always occur when findResource or getDeviceInfo is called, and it
shouldn?t depend on the value of connectivity type included in the call.
Furthermore, the application should be able to choose what (combination of)
adapter(s) the discovery should occur on.
? The current definition will make it hard for us to provide robust
control over multiple interfaces after we merge Ethernet and WiFi. Once we
give the user access to eth1 and wlan1, we need to give the user independent
access to them, and the current definition doesn?t allow that in a scalable way.
Fortunately, there is a simple solution to this dilemma. We can simply adopt a
new definition of OCConnectivityType that is the same as CAConnectivityType.
The advantages are:
? Bits representing independent adapter(s) can be combined in any
combination. This will provide a great deal more capability and flexibility to
applications.
? After fixing the OCDoResource bug, findResource and getDeviceInfo can
be used on any single adapter or combination of adapters.
? The ugly conversion functions back and forth between OCConnectivityType
and CAConnectivityType can be removed. (That unneeded code will only get worse
as we grow the number adapters.)
? After we combine the Ethernet and Wi-Fi adapters, the new
OCConnectivityType can be transparently converted to applying the bits to
interfaces rather than adapters.
If we adopt the current definition of OCConnectivityType, we will be tying our
hands, confining applications, and ensuring that we will need to change the API
yet again. Let?s fix this now.
John Light
(BTW, the code to fix the OCDoResource problem described above is in the
ca-ipv6 code currently in Gerrit. It?s a simple fix, and it simplifies the
code.)
From: iotivity-dev-bounces at lists.iotivity.org
[mailto:[email protected]] On Behalf Of Kesavan, Vijay S
Sent: Tuesday, March 31, 2015 7:57 PM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] CA and master merge ? API changes to base stack
All,
When CA branch is merged with master it will impact the C and C++ APIs for the
base (Iotivity) stack. This impact is result of supporting more than one
adaptor, not currently available in master. The API changes are documented in
the attached file. Please review the changes so that services and/or sample
applications can be updated accordingly. A majority of changes relate to
selecting the adaptor, so to ensure the existing code compiles in the CA
branch, we have defaulted to WiFi adaptor, but it will be prudent to review the
logic and handle adaptor selection appropriately. Changes can be done either
in the CA branch prior to master merge or on master branch after the merge.
Please note the following about the merge:
1. The initial merge will support one Ethernet and one WiFi adaptor active
simultaneously ? intent of the merge is to introduce CA into the lower stack
and showcase that a client can discover resource over multiple interfaces and
it is possible to perform operations on the resource over multiple interfaces.
2. Support for BT, BLE, IPv6 adaptors, including multiple instances of the
same adaptor, is in the pipeline. The CA contributors have said that future
version of CA is going to treat Ethernet and WiFi adaptor as IP adaptor. To
support these and based on some very good discussions in the mailing list on
handling interfaces, a modified set of stack APIs will be proposed.
Regards,
--Vijay
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150401/a086c3c7/attachment.html>
