@@ -174,24 +174,41 @@ Remote protocol
174
174
175
175
This section explains the protocol that is used between the Remote
176
176
library and remote servers. This information is mainly targeted for
177
- people who want to create new remote servers. The provided Python and
178
- Ruby servers can also be used as examples.
177
+ people who want to create new remote servers.
179
178
180
179
The remote protocol is implemented on top of `XML-RPC `_, which is a
181
180
simple remote procedure call protocol using XML over HTTP. Most
182
181
mainstream languages (Python, Java, C, Ruby, Perl, Javascript, PHP,
183
182
...) have a support for XML-RPC either built-in or as an extension.
184
183
184
+ The `Python remote server `__ can be used as a reference implementation.
185
+
186
+ __ https://github.com/robotframework/PythonRemoteServer
187
+
185
188
Required methods
186
189
~~~~~~~~~~~~~~~~
187
190
188
- A remote server is an XML-RPC server that must have the same methods in its
189
- public interface as the `dynamic library API `_ has. Only `get_keyword_names `
190
- and `run_keyword ` are actually required, but `get_keyword_arguments `,
191
- `get_keyword_types `, `get_keyword_tags ` and `get_keyword_documentation ` are
192
- also recommended. Notice that using the camelCase format like `getKeywordNames `
193
- in method names is not possible similarly as in the normal dynamic API. How
194
- the actual keywords are implemented is not relevant for the Remote
191
+ There are two possibilities how remote servers can provide information about
192
+ the keywords they contain. They are briefly explained below and documented
193
+ more thoroughly in the subsequent sections.
194
+
195
+ 1. Remote servers can implement the same methods as the `dynamic library API `_
196
+ has. This means `get_keyword_names ` method and optional `get_keyword_arguments `,
197
+ `get_keyword_types `, `get_keyword_tags ` and `get_keyword_documentation ` methods.
198
+ Notice that using "camel-case names" like `getKeywordNames ` is not
199
+ possible similarly as in the normal dynamic API.
200
+
201
+ 2. Starting from Robot Framework 4.0, remote servers can have a single
202
+ `get_library_information ` method that returns all library and keyword
203
+ information as a single dictionary. If a remote server has this method,
204
+ the other getter methods like `get_keyword_names ` are not used at all.
205
+ This approach has the benefit that there is only one XML-RPC call to get
206
+ information while the approach explained above requires several calls per
207
+ keyword. With bigger libraries the difference can be significant.
208
+
209
+ Regardless how remote servers provide information about their keywords, they
210
+ must have `run_keyword ` method that is used when keywords are executed.
211
+ How the actual keywords are implemented is not relevant for the Remote
195
212
library. Remote servers can either act as wrappers for the real test
196
213
libraries, like the available `generic remote servers `_ do, or they can
197
214
implement keywords themselves.
@@ -206,30 +223,31 @@ The method, and also the exposed keyword, should return `True`
206
223
or `False ` depending on whether stopping is allowed or not. That makes it
207
224
possible for external tools to know if stopping the server succeeded.
208
225
209
- Performance improvements at load-time can be achieved by implementing the
210
- `get_library_information ` method. When supported by the remote server, Robot
211
- Framework will utilize this method to load all information in a single call.
212
- Without `get_library_information `, all `get_keyword_* ` methods will be invoked
213
- separately for each individual keyword, causing significant delays when loading
214
- large libraries.
215
-
216
- The `Python remote server `__ can be used as a reference implementation.
226
+ Using `get_keyword_names ` and keyword specific getters
227
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
217
228
218
- __ https://github.com/robotframework/PythonRemoteServer
229
+ This section explains how the Remote library gets keyword names and other
230
+ information when the server implements `get_keyword_names `. The next sections
231
+ covers using the newer `get_library_info ` method.
219
232
220
- Getting remote keyword names and other information
221
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
233
+ The `get_keyword_names ` method must return names of the keyword the server
234
+ contains as a list of strings. Remote servers can, and should, also implement
235
+ `get_keyword_arguments `, `get_keyword_types `, `get_keyword_tags ` and
236
+ `get_keyword_documentation ` methods to provide more information about
237
+ the keywords. All these methods take the name of the keyword as an argument
238
+ and what they must return is explained in the table below.
222
239
223
- The Remote library gets the list of keywords that a remote server provides
224
- by using the `get_keyword_names ` method. Remote servers must implement this
225
- method and the method must return keyword names as a list of strings.
240
+ .. table :: Keyword specific getter methods
241
+ :class: tabular
226
242
227
- Remote servers can, and should, also implement `get_keyword_arguments `,
228
- `get_keyword_types `, `get_keyword_tags ` and `get_keyword_documentation `
229
- methods to provide more information about the keywords. All these methods
230
- take the name of the keyword as an argument. Arguments must be returned as
231
- a list of strings in the `same format as with dynamic libraries `__, tags
232
- `as a list of strings `__, and documentation `as a string `__.
243
+ =========================== ======================================
244
+ Method Return value
245
+ =========================== ======================================
246
+ `get_keyword_arguments ` Arguments as a list of strings in the `same format as with dynamic libraries `__.
247
+ `get_keyword_types ` Type information as a list or dictionary of strings. See below for details.
248
+ `get_keyword_documentation ` Documentation as a string.
249
+ `get_keyword_tags ` Tags as a list of strings.
250
+ =========================== ======================================
233
251
234
252
Type information can be returned either as a list mapping type names to
235
253
arguments based on position or as a dictionary mapping argument names to
@@ -238,25 +256,69 @@ type names directly. In practice this works the same way as when
238
256
The difference is that because the XML-RPC protocol does not support
239
257
arbitrary values, type information needs to be specified using type names
240
258
or aliases like `'int' ` or `'integer' `, not using actual types like `int `.
241
- Additionally `None ` or `null ` values may not be allowed, and the empty
242
- string should be used instead if a marker telling certain argument does
243
- not have type information is needed .
259
+ Additionally `None ` or `null ` values may not be allowed by the XML-RPC server,
260
+ but an empty string can be used to indicate that certain argument does not
261
+ have type information instead .
244
262
245
263
Remote servers can also provide `general library documentation `__ to
246
- be used when generating documentation with the Libdoc _ tool.
247
-
248
- .. note :: `get_keyword_tags` is new in Robot Framework 3.0.2.
249
- With earlier versions keyword tags can be `embedded into the
250
- keyword documentation `__.
264
+ be used when generating documentation with the Libdoc _ tool. This information
265
+ is got by calling `get_keyword_documentation ` with special values `__intro__ `
266
+ and `__init__ `.
251
267
252
268
.. note :: `get_keyword_types` is new in Robot Framework 3.1.
253
269
254
270
__ `Getting keyword arguments `_
255
- __ `Getting keyword tags `_
256
- __ `Getting keyword documentation `_
257
271
__ `Specifying argument types using @keyword decorator `_
258
272
__ `Getting general library documentation `_
259
- __ `Getting keyword tags `_
273
+
274
+ Using `get_library_information `
275
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
276
+
277
+ The `get_library_information ` method allows returning information about the whole
278
+ library in one XML-RPC call. The information must be returned as a dictionary where
279
+ keys are keyword names and values are nested dictionaries containing keyword information.
280
+ The dictionary can also contain separate entries for generic library information.
281
+
282
+ The keyword information dictionary can contain keyword arguments, documentation,
283
+ tags and types, and the respective keys are `args `, `doc `, `tags ` and `types `.
284
+ Information must be provided using same semantics as when `get_keyword_arguments `,
285
+ `get_keyword_documentation `, `get_keyword_tags ` and `get_keyword_types ` discussed
286
+ in the previous section. If some information is not available, it can be omitted
287
+ from the info dictionary altogether.
288
+
289
+ `get_library_information ` supports also returning general library documentation
290
+ to be used with Libdoc _. It is done by including special `__intro__ ` and `__init__ `
291
+ entries into the returned library information dictionary.
292
+
293
+ For example, a Python library like
294
+
295
+ .. sourcecode :: python
296
+
297
+ """Library documentation."""
298
+
299
+ from robot.api.deco import keyword
300
+
301
+ @keyword(tags=['x', 'y'])
302
+ def example(a: int, b=True):
303
+ """Keyword documentation."""
304
+ pass
305
+
306
+ def another():
307
+ pass
308
+
309
+
310
+ could be mapped into this kind of library information dictionary::
311
+
312
+ {
313
+ '__intro__': {'doc': 'Library documentation'}
314
+ 'example': {'args': ['a', 'b=True'],
315
+ 'types': ['int'],
316
+ 'doc': 'Keyword documentation.',
317
+ 'tags': ['x', 'y']}
318
+ 'another: {'args': []}
319
+ }
320
+
321
+ .. note :: `get_library_information` is new in Robot Framework 4.0.
260
322
261
323
Executing remote keywords
262
324
~~~~~~~~~~~~~~~~~~~~~~~~~
0 commit comments