Currently developer use the findResource API by both ways. findResource (?multicast,?,OC_ALL) ? find all resources from multi connectivity
findResource (?unicast,?,OC_ALL) ? find all resources from multi connectivity or Error return due to Invalid OC_ALL usage. Vijay, What should be the expectation? Could you set up the policy for this question? BR, Uze Choi From: ASHOKBABU CHANNA [mailto:[email protected]] Sent: Wednesday, June 03, 2015 4:07 PM To: Shetty, Mandeep; Kesavan, Vijay S; Uze Choi; Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org Subject: Re: RE: [dev] [OC_ALL defect for unicast discovery and presence] : API does not work properly after CA code change Mandeep, Yes CASendRequestToAll cannot be used for unicast discovery. It supposed to be CASendRequest. If OC_ALL is used for unicast discovery, RI layer need to create Remote endpoints using CA APIs with all supported transports or return error as OC_ALL not supported. If we can aggregate resource endpoints using server UUID for different transports in RI Layer, It can use the endpoints for sending unicast discovery for OC_ALL. In any case CA layer has the APIs. ( CACreateRemoteEndpoint /CASendRequest) Vijay, as per our initial discussions, this aggregation of endpoints based on UUID will be implemented in RI. Correct me if I am wrong. Regards, Ashok ------- Original Message ------- Sender : Shetty, Mandeep<mandeep.shetty at intel.com> Date : Jun 03, 2015 09:03 (GMT+09:00) Title : RE: [dev] [OC_ALL defect for unicast discovery and presence] : API does not work properly after CA code change Ashok, Our understanding is that using OC_ALL requires CASendRequestToAll be called. CASendRequestToAll however accepts a group endpoint CAGroupEndpoint_t. Calling CASendRequestToAll for unicast discovery that Uze originally asked does not make sense in context. Regards, Mandeep. From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ASHOKBABU CHANNA Sent: Tuesday, June 2, 2015 2:24 AM To: Kesavan, Vijay S; Uze Choi; Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] [OC_ALL defect for unicast discovery and presence] : API does not work properly after CA code change Vijay, Could you elaborate more on what you mean by "underlying CA APIs that is called for OC_ALL works only for multicast address"? CA APIs such as CASendRequestToAll can be used for each supported transport if we need to send unicast discovery. Regards, Ashok ------- Original Message ------- Sender : Kesavan, Vijay S<vijay.s.kesavan at intel.com> Date : Jun 02, 2015 14:29 (GMT+09:00) Title : Re: [dev] [OC_ALL defect for unicast discovery and presence] : API does not work properly after CA code change Currently OC_ALL is valid only for multicast discovery and not for the unicast case (reason being the underlying CA APIs that is called for OC_ALL works only for multicast address). --Vijay From: ???(Uze Choi) [mailto:[email protected]] Sent: Monday, June 01, 2015 1:16 AM To: Kesavan, Vijay S; Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org Subject: [OC_ALL defect for unicast discovery and presence] : API does not work properly after CA code change Hi Vijay/Pat OC_ALL is still problem for unicast discovery and presence with subscribePresence() API. Temporarily we are switching the code OC_ALL into OC_IPv4 which causes the code maintenance issue. Previous commit https://gerrit.iotivity.org/gerrit/922 is valid only for specific connectivity but not applicable to OC_ALL. Could you share the plan to support it? According to your answer, I?ll decide the code submit whether we change it (OC_ALL ? OC_IPv4 ? OC_ALL) or wait your bugfixing. BR, Uze Choi From: Kesavan, Vijay S [mailto:[email protected]] Sent: Thursday, May 07, 2015 10:55 AM To: uzchoi at samsung.com Cc: iotivity-dev at lists.iotivity.org Subject: RE: API does not work properly after CA code change Uze ? the OC APIs have not been modified in this changeset to remove the distinction between Ethernet and WiFi. We are working on that and expect a separate changeset in the near future. --Vijay From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Kesavan, Vijay S Sent: Wednesday, May 06, 2015 6:36 PM To: uzchoi at samsung.com Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] API does not work properly after CA code change Uze ? please check https://gerrit.iotivity.org/gerrit/922 This is a workaround for the presence issue. Unicast discovery is working OK for us. Regards, --Vijay From: ???(Uze Choi) [mailto:[email protected]] Sent: Wednesday, May 06, 2015 4:25 PM To: Kesavan, Vijay S Cc: iotivity-dev at lists.iotivity.org; '???'; '???'; '???'; '???'; '???'; h.marappa at samsung.com Subject: RE: API does not work properly after CA code change Vijay, That?s Great. Please notify when fixed. And share the API change also. Furthermore, are you aware that OC_ALL makes crash? Now, We have a workaround way remedy on the all services code. BR, Uze Choi From: Kesavan, Vijay S [mailto:[email protected]] Sent: Wednesday, May 06, 2015 8:16 PM To: uzchoi at samsung.com Cc: iotivity-dev at lists.iotivity.org; ???; ???; ???; ???; ???; h.marappa at samsung.com Subject: RE: API does not work properly after CA code change We came across this issue as well and are investigating it. Please stay tuned for an update on it. Thanks, --Vijay From: ???(Uze Choi) [mailto:[email protected]] Sent: Wednesday, May 06, 2015 1:33 AM To: Kesavan, Vijay S Cc: iotivity-dev at lists.iotivity.org; ???; ???; ???; ???; ???; h.marappa at samsung.com Subject: API does not work properly after CA code change Hi Vijay, After WiFi and Ethernet connectivity are merged together in the CA, Presence and unicast discovery feature is not working now.(Lastest master branch) Due to this error, WE cannot develop the feature right now. And, Could you share the API change from the RI(Resource Introspection) by unifying WiFi and Ethernet connectivity. OC_WIFI and OC_ETHERNET are not valid anymore and OC_ALL is not working either. I need to prepare the primitive service code change according to the base layer API change. BR, UZe Choi -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150603/168c3a03/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150603/168c3a03/attachment.gif>
