We support global discovery (all interfaces, all transports) and host discovery (specific host on a specified transport - requires identification information for that host eg. IP addr or MAC addr). Interface discovery itself might have sub-scenarios and the following ones are currently supported:
1. Discover resources based on specific transport type - example WiFi, Ethernet, BT, BLE. Note for IP interfaces user has the option of selecting Ethernet vs WiFi. 2. Discover resources across hosts on a specific transport type - for IP interfaces it is possible to discovery on the well-known multicast address What is not supported is selecting the specific interface based on transport type. For example, if there are two WiFi interfaces on the platform, it is not possible to specify which WiFi interface to use. --Vijay -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Wednesday, February 25, 2015 1:52 PM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Host field ignored in findResource On Wednesday 25 February 2015 19:59:56 Prasad, Sudarshan wrote: > Next, while doing connectivity abstraction integration with the > resource introspection layer, there was an additional parameter (for > connectivity type. NOTE: This change is already in connectivity-abstraction > branch. > Eventually, it will be merged to master). On those lines, there are > some changes needed in findResource API such that it also considers > other connectivity endpoints (not only IP address, but for BLE/ BT MAC > address too). The API should operate in one of three modes: 1) global discovery: find all resources on all interfaces, all transports 2) interface discovery: find all resources on one specific interface. Not transport mechanism, interface. For example, I might have both more than one IP-based network enabled and I only want one of the two. The interface name or token needs to come from a previous enumeration using the API. 3) host discovery: find all resources on one specific host, where host here encodes the interface name and transport technology, in addition to its addressing. The host must have come from a previous discovery too. Given that, I see absolutely no need for the user of the API to be able to type an address of any sort. Any kind of target selection short of "global" needs to come from previous API calls (enumeration or discovery). Therefore, I recommend removing the host parameter and instead replacing it with a type whose only public constructor is the copy constructor. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
