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
