Closed domedambrosio closed 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.
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?
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"
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.
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.
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.
done.
Testing your pull request, I found a nasty bug in the coap parsing. Expect some delay before merge. Otherwise it looks good.
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.