adhoc
— Ad-Hoc Commands support (XEP-0050)¶
This subpackage implements support for Ad-Hoc Commands as specified in XEP-0050. Both the client and the server side of Ad-Hoc Commands are supported.
New in version 0.8.
Client-side¶
-
class
aioxmpp.
AdHocClient
(client, *, logger_base=None, dependencies={}, service_order_index=0)[source]¶ Access other entities XEP-0050 Ad-Hoc commands.
This service provides helpers to conveniently access and execute XEP-0050 Ad-Hoc commands.
-
async
supports_commands
(peer_jid)[source]¶ Detect whether a peer supports XEP-0050 Ad-Hoc commands.
- Parameters
peer_jid (
aioxmpp.JID
) – JID of the peer to query- Return type
- Returns
True if the peer supports the Ad-Hoc commands protocol, false otherwise.
Note that the fact that a peer supports the protocol does not imply that it offers any commands.
-
async
get_commands
(peer_jid)[source]¶ Return the list of commands offered by the peer.
- Parameters
peer_jid (
JID
) – JID of the peer to query- Return type
- Returns
List of command items
In the returned list, each
Item
represents one command supported by the peer. Thenode
attribute is the identifier of the command which can be used withget_command_info()
andexecute()
.
-
async
get_command_info
(peer_jid, command_name)[source]¶ Obtain information about a command.
- Parameters
- Return type
- Returns
Service discovery information about the command
Sends a service discovery query to the service discovery node of the command. The returned object contains information about the command, such as the namespaces used by its implementation (generally the XEP-0004 data forms namespace) and possibly localisations of the commands name.
The command_name can be obtained by inspecting the listing from
get_commands()
or from well-known command names as defined for example in XEP-0133.
-
async
execute
(peer_jid, command_name)[source]¶ Start execution of a command with a peer.
- Parameters
- Return type
- Returns
A started command execution session.
Initialises a client session and starts execution of the command. The session is returned.
This may raise any exception which may be raised by
start()
.
-
async
-
class
aioxmpp.adhoc.service.
ClientSession
(stream, peer_jid, command_name, *, logger=None)[source]¶ Represent an Ad-Hoc command session on the client side.
- Parameters
stream (
StanzaStream
) – The stanza stream over which the session is established.peer_jid (
JID
) – The full JID of the peer to communicate withcommand_name (
str
) – The command to run
The constructor does not send any stanza, it merely prepares the internal state. To start the command itself, use the
ClientSession
object as context manager or callstart()
.Note
The client session returned by
AdHocClient.execute()
is already started.The command_name must be one of the
node
values as returned byAdHocClient.get_commands()
.-
async
start
()[source]¶ Initiate the session by starting to execute the command with the peer.
- Returns
The
first_payload
of the response
This sends an empty command IQ request with the
EXECUTE
action.The
status
,response
and related attributes get updated with the newly received values.
-
async
proceed
(*, action=<ActionType.EXECUTE: 'execute'>, payload=None)[source]¶ Proceed command execution to the next stage.
- Parameters
action (
ActionTyp
) – Action type for proceedingpayload – Payload for the request, or
None
- Returns
The
first_payload
of the response
action must be one of the actions returned by
allowed_actions
. It defaults toEXECUTE
, which is (alongside withCANCEL
) always allowed.payload may be a sequence of XSOs, a single XSO or
None
. If it isNone
, the XSOs from the request are re-used. This is useful if you modify the payload in-place (e.g. viafirst_payload
). Otherwise, the payload on the request is set to the payload argument; if it is a single XSO, it is wrapped in a sequence.The
status
,response
and related attributes get updated with the newly received values.
The following attributes change depending on the stage of execution of the command:
-
allowed_actions
¶ Shorthand to access
allowed_actions
of theresponse
.If no response has been received yet or if the response specifies no set of valid actions, this is the minimal set of allowed actions (
EXECUTE
andCANCEL
).
Server-side¶
-
class
aioxmpp.adhoc.
AdHocServer
(client, **kwargs)[source]¶ Support for serving Ad-Hoc commands.
-
register_stateless_command
(node, name, handler, *, is_allowed=None, features={'jabber:x:data'})[source]¶ Register a handler for a stateless command.
- Parameters
node (
str
) – Name of the command (node
in the service discovery list).name (
str
orLanguageMap
) – Human-readable name of the commandhandler – Coroutine function to run to get the response for a request.
is_allowed (function or
None
) – A predicate which determines whether the command is shown and allowed for a given peer.features (
set
ofstr
) – Set of features to announce for the command
When a request for the command is received, handler is invoked. The semantics of handler are the same as for
register_iq_request_handler()
. It must produce a validCommand
response payload.If is_allowed is not
None
, it is invoked whenever a command listing is generated and whenever a command request is received. Theaioxmpp.JID
of the requester is passed as positional argument to is_allowed. If is_allowed returns false, the command is not included in the list and attempts to execute it are rejected with<forbidden/>
without calling handler.If is_allowed is
None
, the command is always visible and allowed.The features are returned on a service discovery info request for the command node. By default, the XEP-0004 (Data Forms) namespace is included, but this can be overridden by passing a different set without that feature to features.
-