1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
/**
*
*
* Task Interface: # Called by the task itself at runtime
*
* tp = vo_taskStart ()
* char *vo_taskGetPackageName (tp)
* char *vo_taskGetTaskName (tp)
* *char = vo_taskGetStringParam (tp, paramName)
* ival = vo_taskGetBoolParam (tp, paramName)
* ival = vo_taskGetIntParam (tp, paramName)
* dval = vo_taskGetBoolParam (tp, paramName)
*
* status = vo_setIntOutputParam (tp, paramName, ival)
* status = vo_setRealOutputParam (tp, paramName, dval)
* status = vo_setStringOutputParam (tp, paramName, sval)
* status = vo_setOutputParam (tp, paramName, paramType, paramEncoding,
* *len, **void)
* tp = vo_taskEnd (tp)
*
*
* Notes:
* 1. Task should call vo_taskStart initially to get a runtime context,
* and vo_taskEnd when done to free resources, flush any output, and
* so forth.
* 2. When a task is run in a "connected" (remote) fashion it is passed
* a keyword table of parameter values, via argc/argv or whatever.
* True host level, CLI (argc/argv) mode can be provided as
* well in which case all the -help etc. generics can be provided by
* the task main (container).
* Defaulting can be performed task-side if provided.
* 3. Input parameters can be retrieved by name (do we need to walk a
* list as well? probably not in this case).
* 4. Output parameters are flushed through to the client in each
* setOutputParam call, allowing interactive output at runtime. A
* single output parameter may be set multiple times, e.g.,
* for stdout, warning, status, etc. this could be normal. The
* client tasking code accumulates output parameters in an output
* param set during execution. Whether or not parameters are passed
* on to a client callback is up to the client.
*
* Whether or not a task executes directly in the client process or in a
* separate process is transparent to the client; normally tasks will execute
* in a subprocess.
*
*/
#include "voTask.h"
|
