plugin XEP-0353, XEP-0234, jingle: WebRTC data channel signaling implementation: Implement XEP-0343: Signaling WebRTC Data Channels in Jingle. The current version of the XEP (0.3.1) has no implementation and contains some flaws. After discussing this on xsf@, Daniel (from Conversations) mentioned that they had a sprint with Larma (from Dino) to work on another version and provided me with this link: https://gist.github.com/iNPUTmice/6c56f3e948cca517c5fb129016d99e74 . I have used it for my implementation. This implementation reuses work done on Jingle A/V call (notably XEP-0176 and XEP-0167 plugins), with adaptations. When used, XEP-0234 will not handle the file itself as it normally does. This is because WebRTC has several implementations (browser for web interface, GStreamer for others), and file/data must be handled directly by the frontend. This is particularly important for web frontends, as the file is not sent from the backend but from the end-user's browser device. Among the changes, there are: - XEP-0343 implementation. - `file_send` bridge method now use serialised dict as output. - New `BaseTransportHandler.is_usable` method which get content data and returns a boolean (default to `True`) to tell if this transport can actually be used in this context (when we are initiator). Used in webRTC case to see if call data are available. - Support of `application` media type, and everything necessary to handle data channels. - Better confirmation message, with file name, size and description when available. - When file is accepted in preflight, it is specified in following `action_new` signal for actual file transfer. This way, frontend can avoid the display or 2 confirmation messages. - XEP-0166: when not specified, default `content` name is now its index number instead of a UUID. This follows the behaviour of browsers. - XEP-0353: better handling of events such as call taken by another device. - various other updates. rel 441

=============================================
application: external applications management
=============================================

Libervia can launch and manage external applications. This is useful to integrate external
services, notably in the web frontend. The command can be used either with ``application``
or the shortcut ``app``.

list
====

List available applications. This command can show either the list of available
application (which could be launched) and/or the list of running application.

By default both available and running application are shown, this can be filtered by using
``-f {available,running}, --filter {available,running}``

example
-------

List available applications::

  $ li app list -f available

start
=====

Start an application. Depending on the application and its availability locally, this make
take some time (resources may have to be downloaded).

example
-------

Start Weblate::

  $ li app start weblate

.. _li_app_stop:

stop
=====

Stop an application. If several instances of the same application are running, ``-i ID,
--id ID`` can be used to specify which one must be stopped.

example
-------

Stop Weblate::

  $ li app stop weblate


exposed
=======

List exposed values from a running application. Exposed values may be the port used,
passwords automatically generated, or fields useful for web integration.

As for :ref:`li_app_stop`, if several instances of the same application are running, one
can be specified using ``-i ID, --id ID``.

example
-------

Show exposed values of a running Weblate::

  $ li account application exposed weblate