I didn't submit the JIRA bug because I am blocked. I'm not. I just thought I'd point out a leak I found while examining the plumbing.
FYI, the current code introduces IPv4 broadcast address unnecessarily. That I am fixing. John From: Prasad, Sudarshan Sent: Wednesday, February 25, 2015 12:00 PM To: Light, John J; Keane, Erich; iotivity-dev at lists.iotivity.org Subject: RE: Host field ignored in findResource At the initial stages of findResource API, first parameter's intention was indeed to have a host field which will either take IP or could be left blank (which will do multicast). These were in the lines of matching with the required and reference URI concepts. 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). Also, 1.0 version of spec is coming out soon and it would be better to see those details (how it deals with reference, required URI etc.) and refactor accordingly. In short, this findResource API needs to be refactored and plan was to bring up the proposal in the mailing list (when above factors align), discuss it and go ahead in making the changes. We do not want to refactor a public API multiple times and hence we need to align correctly. BTW, with the existing findResource API, would it be okay for you to make changes for IPV6 (without changing the signature of the API)? Wanted to make sure you are not blocked. Thanks, Sudarshan Prasad | Software Development Engineer | Intel Corporation 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: Wednesday, February 25, 2015 11:08 AM To: Keane, Erich; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] Host field ignored in findResource Complicating the issue in the current code base is that a network address in the second field is processed approximately the doc says the first argument is processed. However, I am changing that behavior as part of the IPv6 dev since the currently canned IPv4 address is not generally useful there. I could fix the JIRA bug I submitted in my branch, but then it won't get to master for some time. John From: Keane, Erich Sent: Wednesday, February 25, 2015 10:53 AM To: Light, John J; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: Host field ignored in findResource It is likely a bug that we're ignoring a field like that. I'll note that all of platform/wrappers seem to ignore the first component to that or don't do the broadcast check. 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: Wednesday, February 25, 2015 10:48 AM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] Host field ignored in findResource I submitted a JIRA on this, but I'd like a timely answer since it affects IPv6 work. The first argument to Platform::findResource (and Platform::findDevice) is ignored when the code reaches InProcClientWrapper::ListenForResource (or ListenForDevice). The field can be a host url, but documentation says an empty/null value is treated as broadcast, which is certainly the most common usage. Is this an oversight, a true bug, or intentional? Perhaps the field is being removed? John Light -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150225/201c57b4/attachment.html>
