search

intel / liblwm2m

liblwm2m is an implementation of the LWM2M protocol from the Open Mobile Alliance.
BSD 3-Clause "New" or "Revised" License
44 stars 28 forks source link

create and execute may return values #23

Closed domedambrosio closed 10 years ago

domedambrosio commented 10 years ago

Create must return the Object Instance ID if it wasn't listed in the request. Execute may return values based on the resource description of the object.

dnav commented 10 years ago

Hi, I guess you refer to chapter 8.2.4 of the TS that states: "Note that the behaviour of the “Execute” operation, whether it uses arguments and how those are interpreted, and how it returns values is specified in the Resource description of the Object." My understanding of the LWM2M protocol differs from yours. Here I read that the object description will explain how to access the returned values (by reading a resource for instance) not that the CoAP response will contain a payload.

Regarding the create operation, there is indeed an issue: we should return the ID of the newly created instance if it is not specified in the URI. But my understanding here is that this location is in the URI field of the response not in the payload (I have to check this) For the object to return the new instance ID, it can update the URI pointer in its callback.

Let me know your thoughts.

domedambrosio commented 10 years ago

Yes I refer to that chapter.

For the Execute I think both our interpretation are correct. The Firmware Object with "Update" and "Update Results" resources is an exemple of your interpretation but I think a Resource description that specify that the results will be contained in the CoAP response still comply with the "how it returns values is specified in the Resource description of the Object" part.

About the Create, using the URI option is a way (the TS say only to "send back" the instanceID) but it feels wrong to send a response with an URI different from the one in the request, also because the URI is only used in request message. Anyway, shouldn't the packet be smaller (then more efficent for the network) if only the InstanceID is returned in the payload?

dnav commented 10 years ago

Regarding the Create, the answer lies in the CoAP specification (http://tools.ietf.org/html/draft-ietf-core-coap-18) section 5.8.2: "If a resource has been created on the server, the response returned by the server SHOULD have a 2.01 (Created) response code and SHOULD include the URI of the new resource in a sequence of one or more Location-Path and/or Location-Query Options (Section 5.10.7)."

and section 5.10.7 states that: "Each Location-Path Option specifies one segment of the absolute path to the resource"

domedambrosio commented 10 years ago

I have updated the code for the create with the Location-Path mechanism. Let me know if the server part (location-path parsed in dm_result_callback() and assigned to uriP) is ok for you.

dnav commented 10 years ago

Hi, Code looks fine. I will test it more. However, could you split your commit in two parts, please ? One for the Create change and one for the Execute change. I haven't made up my mind yet on the Execute returning a payload. My concern is that at CoAP level this payload can not be cached (see section 5.9.1.4 of coap-18) unlike the one for a Read.

domedambrosio commented 10 years ago

ok, I'll split the commits. About your concern for the Execute: I think the response from an execute should not be cached because I expect the result to be fresh, not a cached one.

domedambrosio commented 10 years ago

done.

dnav commented 10 years ago

Testing your pull request, I found a nasty bug in the coap parsing. Expect some delay before merge. Otherwise it looks good.