Gabriel, I am sorry this is happening. When I did the new address plumbing this was not a problem. It was assumed that there were two ways to address in OCDoResource:
Backward compatible: put the address in the resourceURI string and modify its behavior with OCConnectivityType. This was done if the OCDevAddr (destination) was void. Moving forward: if destination (OCDevAddr) was not null, use it exclusively for addressing, ignoring OCConnectivityType and any addressing in resourceURI. (OCDevAddr contains all the elements of OCConnecivityType.) If this approach were still in effect, there would be no need to provide the tuple you find necessary. It is unfortunate that contributors with little understanding of the stack are allowed to make such fundamental changes. Each such mistaken change leads to another mistaken change, adding to our technical debt and confusing potential developers. John Light -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Schulhof, Gabriel Sent: Monday, September 28, 2015 2:24 AM To: iotivity-dev at lists.iotivity.org Subject: [dev] CT_DEFAULT doesn't work anymore While testing IOT-733 with the latest changeset (which I'm sorry to say didn't fix the server-side crash) I noticed that CT_DEFAULT doesn't work for issuing an observe request anymore. I had to modify client.c to use CT_ADAPTER_IP | CT_IP_USE_V6 for the observe request instead of CT_DEFAULT, which is what I was using so far. When I tried CT_DEFAULT, My observe OCClientResponse->result was 29 (OC_STACK_COMM_ERROR) and the payload was null. Why doesn't CT_DEFAULT work anymore? I thought one of the major attractions of this stack was that you didn't need to worry about what the communication mechanism was, allowing you to concentrate on the resources themselves. I've noticed that you can derive the right value for the OCConnectivityType from the information inside OCDevAddr by looking at ->adapter and ->flags, but it would be really nice if I didn't have to. Is it possible to provide an API for converting an OCDevAddr to a OCConnectivityType? Alternatively connType could become part of OCDevAddr (it already kind of is), since client applications now need to maintain a tuple (OCDevAddr, OCConnectivityType) for use in OCDoResource() calls anyway. Cheers! Gabriel _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
