core, frontends: avatar refactoring: /!\ huge commit Avatar logic has been reworked around the IDENTITY plugin: plugins able to handle avatar or other identity related metadata (like nicknames) register to IDENTITY plugin in the same way as for other features like download/upload. Once registered, IDENTITY plugin will call them when suitable in order of priority, and handle caching. Methods to manage those metadata from frontend now use serialised data. For now `avatar` and `nicknames` are handled: - `avatar` is now a dict with `path` + metadata like `media_type`, instead of just a string path - `nicknames` is now a list of nicknames in order of priority. This list is never empty, and `nicknames[0]` should be the preferred nickname to use by frontends in most cases. In addition to contact specified nicknames, user set nickname (the one set in roster) is used in priority when available. Among the side changes done with this commit, there are: - a new `contactGet` bridge method to get roster metadata for a single contact - SatPresenceProtocol.send returns a Deferred to check when it has actually been sent - memory's methods to handle entities data now use `client` as first argument - metadata filter can be specified with `getIdentity` - `getAvatar` and `setAvatar` are now part of the IDENTITY plugin instead of XEP-0054 (and there signature has changed) - `isRoom` and `getBareOrFull` are now part of XEP-0045 plugin - jp avatar/get command uses `xdg-open` first when available for `--show` flag - `--no-cache` has been added to jp avatar/get and identity/get - jp identity/set has been simplified, explicit options (`--nickname` only for now) are used instead of `--field`. `--field` may come back in the future if necessary for extra data. - QuickContactList `SetContact` now handle None as a value, and doesn't use it to delete the metadata anymore - improved cache handling for `metadata` and `nicknames` in quick frontend - new `default` argument in QuickContactList `getCache`

==================================
info: retrieve various information
==================================

``info`` groups subcommands used to retrieve read-only informations.

disco
=====

Display discovery information (see `XEP-0030`_ for details). This can be used to check
which features you server or a service is offering, and which items are available (items
can be services like chat room, gateways, etc).

You only have to specify the jid of the entity to check, and optionally a node.

By default both infos and items are requested, but you can restrict what to request by
using ``-t {infos,items,both}, --type {infos,items,both}``

.. _XEP-0030: https://xmpp.org/extensions/xep-0030.html


example
-------

Request infos and items from a server::

  $ jp info disco example.org

version
=======

Request software version of an entity. You only need to specify the jid of the entity as
positional argument.

Depending of the software and its configuration, you have software version, software name,
and the operating system on which the software is running.

example
-------

Check version of a server::

  $ jp info version example.org

session
-------

Give information about the session of the given profile. You'll get the full jid currently
used on the server, and the time when the session was started (which may not be the same
time as when the connection with the XMPP server was started).

example
-------

Get session informations::

  $ jp info session

devices
-------

List known devices for an entity. You'll get resource name, and data such as presence
data, and identities (i.e. name and type of the client used).

If entity's bare jid is not specified, a list of your own devices is returned.

example
-------

List known devices of Louise::

  $ jp info devices louise@example.org

Check if we have other devices connected::

  $ jp info devices