Hi John, Please find my comments inlined below.
* What about OC_ALL? That seems to be inconsistent with your explanation. * ****** With current code base, OC_ALL covers only ETHERNET and WIFI, because BLE/EDR are not supported in all the platforms (e.g. Ubuntu). * Is it expected that I will eventually be able to do a single FindResource on multiple networks? I think I heard you say that. >>>>>>>> Yes. * Is it expected in the meantime that I might do multiple FindResource calls, each on a different network? >>>>>>>> Yes and No. * No, You can send one findResource request on all interfaces (today it is WIFI and ETHERNET) using OC_ALL. * Yes. Lets say we have BLE enabled in future, and if you want to send a request on BLE and WIFI and not on ETHERNET. Then with the current OCConnectivityType implementation, you need to send multple findResource requests on each interface (one for BLE and one for WIFI). We are planning to revisit C++ APIs (findResource, etc), and C APIs (OCDoResource, etc) with respect to OCConnectivityType. For now, we are taking the least resistance path to do the merge from CA to master. Sudarshan/Vijay : Please correct if I missed any other points. Thank you, Sashi. From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Light, John J Sent: Friday, January 30, 2015 10:43 AM To: Kesavan, Vijay S; iotivity-dev at lists.iotivity.org Subject: Re: [dev] OCConnectivityType Vijay, Thank you for your cogent response. I'm obviously suffering from a lack of perspective. Some additional question do arise: * What about OC_ALL? That seems to be inconsistent with your explanation. * Is it expected that I will eventually be able to do a single FindResource on multiple networks? I think I heard you say that. * Is it expected in the meantime that I might do multiple FindResource calls, each on a different network? John From: Kesavan, Vijay S Sent: Friday, January 30, 2015 10:14 AM To: Light, John J; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: OCConnectivityType John - let me take a stab at it. Firstly, I want to mention that the point you raise is specific to the connectivity-abstraction branch (current time) and is not applicable to master - just clarifying to avoid confusing anyone not following CA branch. At the OC API level the connectivity type is used to specify the interface to use for APIs related to find resource, subscribe presence, device discovery (equivalent C++/C APIs). Prior to invoking these APIs, it is assumed that OCInit has initialized the adapters of interest. Internally, this happens by calling CASelectNetwork - where a bit mask of connectivity types makes sense, however the select network API is not (yet) exposed at the stack level (as an OC API). Also note that the connectivity type is returned in the callback as part of OCResource object to indicate on which adapter type the response was received. To understand why OCConnectivityType is not a bit mask let's use findResource as an example. One of the parameters of findResource is resourceURI which indicates the URI to use in discovery, which could be of the form <IP addr>:<port>/oc/core - this URI is applicable to IP networks only (Ethernet and WiFi) and not non-IP networks like BLE/EDR. So selecting EDR and WiFi in OCConnectivityType does not make sense. If OCConnectivityType were a bit mask certain combinations of adapter types have to be filtered out in some APIs. Instead of that the definition allows selecting only a specific connectivity type OR selecting ALL connectivity types and not a subset of types. --Vijay PS: There is a plan to change findResource API to abstract the API and not requiring the user to specify "/oc/core" but that is a separate discussion. From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Light, John J Sent: Friday, January 30, 2015 8:52 AM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] OCConnectivityType In ocstack.h the CA connectivity types are defined: typedef enum { OC_ETHERNET = 0, OC_WIFI, OC_EDR, OC_LE, OC_ALL //Multicast message: send over all the interfaces. } OCConnectivityType; Shouldn't this be defined more like typedef enum { OC_ETHERNET = 1, OC_WIFI = 2, OC_EDR = 4, OC_LE = 8, OC_ALL = 0xfffffffff, //Multicast message: send over all the interfaces. OC_DEFAULT = 2 // used for FindResource } OCConnectivityType; OC_ALL is interesting, but I should be able to pick just EDR and WIFI. Of course, this will also affect the underlying plumbing. John Light -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150130/9258bfe0/attachment.html>
