You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: devguide/howtos/add-function.md
+19-8Lines changed: 19 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,8 +24,8 @@ The function to describe the new message will look something like the following:
24
24
~name:"price_of"
25
25
~in_oss_since:None
26
26
~in_product_since:rel_orlando
27
-
~params:[Ref _host, "host", "The host containing the price information";
28
-
String, "item", "The item whose price is queried"]
27
+
~params:[(Ref _host, "host", "The host containing the price information");
28
+
(String, "item", "The item whose price is queried")]
29
29
~result:(Float, "The price of the item")
30
30
~doc:"Returns the price of a named item."
31
31
~allowed_roles:_R_POOL_OP
@@ -49,22 +49,33 @@ The parameters passed to call are all optional (except ~name and ~in_product_sin
49
49
presence of an existing session.
50
50
51
51
- The value of the ~in_product_since parameter is a string taken from
52
-
`idl/datamodel_types.ml`indicating the XenServer release in which this
52
+
`idl/datamodel_types.ml`indicates the XenServer release in which this
53
53
message was first introduced.
54
54
55
55
- The ~params parameter describes a list of the formal parameters of the message.
56
56
Each parameter is described by a triple. The first component of the triple is
57
57
the type (from type ty in `idl/datamodel_types.ml`); the second is the name
58
-
of the parameter; the third is a human-readable description of the parameter.
58
+
of the parameter, and the third is a human-readable description of the parameter.
59
59
The first triple in the list is conventionally the instance of the class on
60
60
which the message will operate. In the example, this is a reference to the host.
61
61
62
62
- Similarly, the ~result describes the message's return type, although this is
63
63
permitted to merely be a single value rather than a list of values. If no
64
64
~result is specified, the default is unit.
65
65
66
+
- The ~doc parameter describes what the message is doing.
67
+
68
+
- The bool ~hide_from_docs parameter prevents the message from being included in the documentation when generated.
69
+
70
+
- The bool ~pool_internal parameter is used to indicate if the message should be callable by external systems or only internal hosts.
71
+
72
+
- The ~errs parameter is a list of possible exceptions that the message can raise.
73
+
74
+
- The parameter ~lifecycle takes in an array of (Status, version, doc) to indicate the lifecycle of the message type. This takes over from ~in_oss_since which indicated the release that the message type was introduced. NOTE: Leave this parameter empty, it will be populated on build.
75
+
66
76
- The ~allowed_roles parameter is used for access control (see below).
67
77
78
+
68
79
Compiling `xen-api.(hg|git)` will cause the code corresponding to this message
69
80
to be generated and output in `ocaml/xapi/server.ml`. In the example above, a
70
81
section handling an incoming call host.price_of appeared in `ocaml/xapi/server.ml`.
0 commit comments