Design API for scheduling operation invocations

[danbim]

An additional timestamp field can be used to schedule operations for future execution. An example use case is the gateway (NTP) time-synchronized reset of nodes. Another use case is a complete scheduled (automated) experiment execution.

After a scheduling request is received it will be forwarded to the responsible gateways and a status is returned indicating that the operation has been scheduled. Later, during execution status codes are sent to the controller as was the case before (e.g. 0 to 100 for flash progress).

• Support for scheduling is optional, i.e. if a timestamp but scheduling is not supported an error message will be returned that indicates that the scheduling is not yet supported.
• If supported, API implementations such as Testbed Runtime should schedule the operations physically as near as possible to the nodes that the operations will run on (e.g. the gateways).

[danbim]

Btw... thanks to Moritz Strübe for this excellent suggestion!

[danbim]

Some comments from Evangelos:

- experiment description in form of set of iWSN commands ?
- storing in some DB the experiment output messages gathered from nodes?
- in the issue you mention somehow that the GW eventually will execute the scheduled commands ? Do you think
that the GW will queue up all these future commands (depending on how far in the future maybe you need more memory?)
and also design a mechanism to discard scheduled commands (in the case an experiment is aborted)?

I think there should be a method that allows to discard scheduled commands. As the client issues request IDs when calling or scheduling an operation he can use the same request ID to later cancel that operation scheduling.

Also, giving the issue a second thought it might be nicer to not add timestamps to the existing operations but to add additional operations with the same name and same argument list + a timestamp. This way, scheduled operations can be moved to the next API version (3.1, which will be downwards compatible) and we can make sure to have a cleaner design without further delaying the release of 3.0. Therefore, the commits will be rolled back now.

[danbim]

Moved this issue to milestone 3.1