Software Management executable resources synchronous or async?

[bryan-aetheros]

Is execution of the Install, Uninstall, Activate, and Deactivate resources of the Software Management object understood to initiate an asynchronous action, as opposed to performing the complete action synchronously before sending the response (success or failure) to the execute request?

A similar question I have is, what should the behavior be when deleting a software instance that is currently in the Installed state? Should a Delete request be interpreted as implicitly requesting an uninstall in this case (which could be performed asynchronously)? And if so, could or should there be any changes to /9/x/7 or /9/x/9 resulting in notifications being delivered before or after the response to the delete request itself.

[sbernard31]

(warning I'm not OMA member and so not a LWM2M author)

You are talking about object LWM2M Software Management object 9 right ?
Which is described here ?

Is execution of the Install, Uninstall, Activate, and Deactivate resources of the Software Management object understood to initiate an asynchronous action, as opposed to performing the complete action synchronously before sending the response (success or failure) to the execute request?

My understanding is when server send an EXECUTE request on one of those resources then client should answer immediately.
With :

• probably a success 2.04 Changed response if it is in the right state and so is OK to start the corresponding process.
• maybe a 4.05 Method not allowed if it is not in the right state. (because of wording in LWM2M Software Management specification "This Resource is only executable when the value of the State Resource is XXXXX" and following error code specification (I'm not so sure about that)

So yes I understand this is async action.

what should the behavior be when deleting a software instance that is currently in the Installed state?

Oh good question.

Should a Delete request be interpreted as implicitly requesting an uninstall in this case (which could be performed asynchronously)?

I don't know what will be the official answer but I will not do that.

I see the object instance as a way to control the software lifecycle.
So when you want to control a new software, you create an object instance for that software.
As long as you need to control (install, update, start, stop, uninstall) this software lifecyle, you keep the object instance.
You only delete the object instance when you don't need to manage the software anymore. (so once it is uninstalled)

So FMPOV, a client should only allow to remove the object instance of a software where Update
State resource is in INITIAL state. (and even maybe Update Result resource = 0)

[bryan-aetheros]

Yes, talking about Software Management Object 9. I agree overall with your interpretation. Unfortunately the spec doesn't remark on any criteria for accepting or rejecting a Delete request.

[sbernard31]

Unfortunately the spec doesn't remark on any criteria for accepting or rejecting a Delete request.

I haven't found anything on the subject, and I agree that it would be a good idea to clarify this point.

[mkgillmore]

The DMSO WG has discussed this issue and the consensus is this issue is implementation dependent and not part of the specification.

[bryan-aetheros]

Doesn't that create a potential problem for interoperability?