Iotivity-node vs spec

[hansmbakker]

While writing the typescript definitions, I came across some things that were different in the spec.

I made a separate issue for the Error classes; here I can document some other parts.

[hansmbakker]

I found that there is an active property on ClientResource and ServerResource (in ClientResource.js and in ServerResource.js) that is not described in the spec. What should I follow?

It looks like it is part of the official C sdk - should the spec be updated?

[hansmbakker]

Polling or no polling - there is a PR by @zolkis that updates the spec but it is not merged yet. What to follow?

[hansmbakker]

In the Client.create( ... ) method there is written that the response is a Resource object but in https://github.com/otcshare/iotivity-node/blob/master/lib/Client.js#L340 I see that a ClientResource is returned. What is right? This one is similar to #108, therefore I close this.

[gabrielschulhof]

IIRC a ClientResource /is/ a Resource.

…

On Mon, Feb 13, 2017 at 10:20 PM, wind-rider ***@***.***> wrote: In the Client.create( ... ) <https://github.com/01org/iot-js-api/blob/master/api/ocf/client.md#41-the-createresource-target-method> method there is written that the response is a Resource object but in https://github.com/otcshare/iotivity-node/blob/master/lib/Client.js#L340 I see that a ClientResource is returned. What is right? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#122 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7k0cWf4TOEFjdYIQPhL2h3I-cfATMCks5rcLr9gaJpZM4L_o3k> .

[hansmbakker]

@gabrielschulhof yes, you're right (I found another issue explaining a similar situation). So I removed that one. Comments on the other points are still welcome :)

[hansmbakker]

I found there is an id property on OcfRequest in its implementation, but I can't find that in the spec. Could you please explain what it is for and whether the spec should be changed?

It seems to be used for requestHandle, but that is not part of the spec. Should I ignore it? ok, fixed in 9c4f92b

[hansmbakker]

For me "resource representation" (see OcfRequest) is unclear - it is used as the type for properties in the Resource dictionary, in the OcfServer.translate( ) callback, in OcfRequest.data and in OcfRequest.respond( ... )

In https://github.com/01org/iot-js-api/blob/master/api/ocf/webidl.md I see that ResourceRepresentation always has a Timestamp, but is that part of the spec?

[hansmbakker]

The ServerResource Server type in the spec does not have an oncreate method but the iotivity-node specification has one. Should it be added to the spec?

[zolkis]

I found that there is an active property on ClientResource and ServerResource (in ClientResource.js and in ServerResource.js) that is not described in the spec. What should I follow?
It looks like it is part of the official C sdk - should the spec be updated?

A client resource is always active, as no one marks it for deletion, so IMHO no need to expose that.
A server resource may be inactive, but then it should simply return errors on requests, or just disposed of. No client will first check whether a server resource is active or not. At least we don't yet have enough experience on how this should behave.

I need to understand the use case of active in the OCF spec to start with - is there a real use case that cannot be encapsulated in implementations and need to be exposed to clients?

[zolkis]

Polling or no polling - there is a PR by @zolkis that updates the spec but it is not merged yet. What to follow?

I'd like to design the API (and the OCF protocol suite) so that no unnecessary polling happens from client side in order to know whether a server is alive or not. Since OCF doesn't fully support that yet, I thought to implement it in the bindings (to keep clients small and discourage client implementations of polling) and convince OCF to do it right (in order to save network bandwidth, e.g. instead of every client polling every server, do a resource directory which maintains resource status and last known values as well).

However, we have found this too complex and iced it for a while.

[zolkis]

I found there is an id property on OcfRequest in its implementation, but I can't find that in the spec. Could you please explain what it is for and whether the spec should be changed?

The id is exposed by the OCF protocol, but encapsulated by the impl. A JS API doesn't really need it.

[zolkis]

For me "resource representation" (see OcfRequest) is unclear - it is used as the type for properties in the Resource dictionary, in the OcfServer.translate( ) callback, in OcfRequest.data and in OcfRequest.respond( ... )

The OCF Core spec defines resource representation. In order to keep it separate from the meta-properties, it is represented as a dictionary property of Resource. The translate() needs to be a client-owned transformation on the representation reflecting its business logic (until we have the Web of Things which will figure out what to do with a data model on its own).

Also, OCF specifies what exactly is sent during protocol requests and responses. Clients may want to interfere with that, so we have exposed these structures.

In https://github.com/01org/iot-js-api/blob/master/api/ocf/webidl.md I see that ResourceRepresentation always has a Timestamp, but is that part of the spec?

In theory it should, I need to check on feasibility...

[zolkis]

The ServerResource type in the spec does not have an oncreate method but the iotivity-node specification has one. Should it be added to the spec?

There is oncreate.

[hansmbakker]

@zolkis thank you for your feedback. I removed the id from the typings.

As for oncreate, I'm sorry - I meant that both the Server implementation has one (not according to spec) and ServerResource (according to spec).

As for the other parts, I find it difficult to decide what it means in practice for #119