Fix missing platform info

[hekra01]

• As defined in the web api, OicDeviceInfo must contain platform info.
• Use case is:
  • perform multicast discovery of devices
  • Expected: for each device the OicDeviceInfo contains device and platform info

Issue:

• At the C API level (OCDoResource and OCClientResponse)
  • Following deivce discovery OCClientResponse provides devAddr
  • So devAddr can be used directly to make a unicast query for the platform info of the device.
• At the C++ API level (OCPlatform::getDeviceInfo and OCRepresentation)
  • there is no such direct link
  • When retrieving device info we have to:
  • retrieve resources from this device
  • then, once the resources are retrieved get the resource host, which is the host of the device
  • then use this host to make a unicast request for each platform info
  • It is possible to do but not efficient in temrs of processing and number of requests sent

Note: this issue is not relevant for iotivity-node as it uses the C API.

@poussa, @zolkis, am I missing something?
Providing host info at OCRepresentation level would simplify things.

[zolkis]

You are right, they should be optional (nullable). And it is a good question if there should be separate function for platform discovery, or should we bound them together, as you seem to have understood.

Looks like the C++ API is out of sync with the OIC Core spec 1.0. Platform should be a core resource on each instance of an OIC device. If getting platform for a device (supposedly a local operation) is not supported in the C++ API, I think we should not work that around in the JS API. We just leave it as null. Or, use the C API...

In general, in the API when we use a structure, it is not guaranteed that a given operation provides all properties of that structure. So it is not a problem if platform info is missing after discovery, but we do need to fix the API, and does need to be documented.

As an example on partial information, when doing device discovery, only a list of device id's (UUID) is returned, eventually together with a list of { resourceURL, resourceType, interfaces } per device. But the (partial) resource list may be missing. If present, a retrieve operation can be made right away, otherwise a resource discovery is needed.

Anyway, I am going to fix the spec. Also, I have added a new file describing the new version of the high level spec. Both are in this PR:
https://github.com/otcshare/iotivity-node/pull/30/files
Take a look, and if you have any feedback, we can still modify the API relatively easily.
It would be nice to get this kind of feedback as early and as much as possible. Thank you!

[hekra01]

Looks like the C++ API is out of sync with the OIC Core spec 1.0. Platform should be a core resource on each instance of an OIC device. If getting platform for a device (supposedly a local operation) is not supported in the C++ API, I think we should not work that around in the JS API. We just leave it as null. Or, use the C API...

In fact the C++ API permits retrieval of both platform and device info (independently), so it complies with the spec there.

The issue is when doing multicast oic/d and oic/p discovery info with C++ API:

• multiple device and platform info are retrieved from all the other hosts on the network.
• But there is no means in the C++ API to map device to platform info.
• In C API this is straightforward using OCClientResponse->devAddr

We just leave it as null.

OK. But then the web API provides no platform info.

Or, use the C API...

OK.
hm, how about fixing the C++ API? E.G: providing host info in OCRepresentation.

[zolkis]

Yes, it needs to be fixed in IoTivity (my point was only that we should not work around it in the JS API). Please file a bug.

[hekra01]

https://jira.iotivity.org/browse/IOT-828

Resolved. Scheduled for IoTivity-1.0.1