This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
The name of a connection manager, found in its well-known bus name and object path. This must be a non-empty string of ASCII letters, digits and underscores, starting with a letter. This is typically the name of the executable with any "telepathy-" prefix removed, and any hyphen/minus signs replaced by underscores.
Connection manager names SHOULD NOT be the same as the name of the protocol they implement.
This is likely to lead to conflicts between different implementations of the same protocol (or indeed inability to distinguish between the different implementations!). The Telepathy project traditionally uses some sort of pun (Haze is based on libpurple, Salut implements a protocol often called Bonjour, and Wilde implements the OSCAR protocol).
Connection manager names SHOULD NOT be the same as the name of a library on which they are based.
We often abbreviate, for instance, telepathy-haze as “Haze”, but abbreviating telepathy-sofiasip—since renamed to telepathy-rakia for exactly this reason—to “Sofia-SIP” caused confusion between the connection manager and the library it uses. Please don't repeat that mistake.
An instant messaging protocol. It must consist only of ASCII letters, digits and hyphen/minus signs (U+002D "-"), and must start with a letter. Where possible, this SHOULD be chosen from the following well-known values:
This parameter should be considered private or secret; for instance, clients should store it in a "password safe" like gnome-keyring or kwallet, omit it from debug logs, and use a text input widget that hides the value of the parameter.
(Clients that support older connection managers may also treat any parameter whose name contains "password" as though it had this flag.)
This parameter is also a D-Bus property on the resulting
com.example.Duck.Macaroni
with this
flag corresponds to the Macaroni
property on the
com.example.Duck
interface. Its value can be queried
and possibly changed on an existing Connection using methods on the
org.freedesktop.DBus.Properties
interface.
When a new value for a parameter with this flag is passed to
Has_Default
flag, and is passed in the second argument
to UpdateParameters
, the default value will be applied
to any running
connections. Thus, clients generally do not need to directly access
or update the connection property; instead, they SHOULD manipulate
This allows runtime-configurable options to be stored and
maintained by the
A map from protocol identifiers supported by a connection
manager to the immutable properties of the corresponding
A map from protocol identifiers supported by this connection
manager to the immutable properties of the corresponding
Providing the immutable properties here means that when the API of Protocol objects has been finalized, most clients will only need one D-Bus round trip to interrogate the ConnectionManager about all its protocols.
If this map is empty or missing, clients SHOULD fall back to
calling
Request a
Most applications should not use this method: they
should instead use the the
The parameters which must and may be provided in the parameters
dictionary can be discovered with the
To request values for these parameters from the user, a client must
have prior knowledge of the meaning of the parameter names, so the
well-known names and types defined by the
Connection manager authors SHOULD avoid introducing parameters
whose default values would not be serializable in a
.manager
file.
The same serialization format is used in Mission Control to store accounts.
Every successful RequestConnection call will cause the emission of a
Well-known connection parameter names, along with their expected
type. Where possible, connection managers should use names and types
from this list in the
The time in seconds between pings sent to the server to ensure that the connection is still alive, or 0 to disable such pings.
This parameter is superseded by the
The following well-known parameter names correspond to D-Bus
properties, and thus their
A list of the extra interfaces provided by this connection manager (i.e. extra functionality that can be provided even before a connection has been created).
No interfaces suitable for listing in this property are currently defined; it's provided as a hook for possible future functionality.
To be compatible with older connection managers, if retrieving this property fails, clients SHOULD assume that its value is an empty list.
Connection managers with a non-empty list of Interfaces MUST
represent them in the .manager
file, if they have one,
as an Interfaces
key in the
group headed [ConnectionManager]
, whose value is a list
of strings each followed by a semicolon.
A D-Bus service which allows connections to be created. The manager processes are intended to be started by D-Bus service activation.
For service discovery, each Telepathy connection manager must have
a connection manager name (see
The connection manager must then provide a well-known bus name of
org.freedesktop.Telepathy.ConnectionManager.cmname
where cmname is its connection manager name. If it makes sense
to start the connection manager using D-Bus service activation, it
must register that well-known name for service activation by installing
a .service file.
Clients can list the running connection managers by calling the ListNames method on the D-Bus daemon's org.freedesktop.DBus interface and looking for names matching the above pattern; they can list the activatable connection managers by calling ListActivatableNames, and they should usually combine the two lists to get a complete list of running or activatable connection managers.
When the connection manager is running, it must have an object
implementing the ConnectionManager interface at the object path
/org/freedesktop/Telepathy/ConnectionManager/cmname
.
Connection managers' capabilities can be determined dynamically by
calling their
To look up a connection manager's supported protocols, clients
should search the data directories specified by
the
freedesktop.org XDG Base Directory Specification ($XDG_DATA_HOME,
defaulting to $HOME/.local/share if unset, followed by
colon-separated paths from $XDG_DATA_DIRS, defaulting to
/usr/local/share:/usr/share if unset) for the first file named
telepathy/managers/cmname.manager
that can be
read without error. This file has the same syntax as a
freedesktop.org Desktop Entry file.
Clients must still support connection managers for which no
.manager
file can be found, which they can do by activating
the connection manager and calling its methods; the
.manager
file is merely an optimization. Connection managers
whose list of protocols can change at any time (for instance, via
a plugin architecture) should not install a .manager
file.
The .manager
file SHOULD have a group headed
[ConnectionManager]
, containing a key
Interfaces
representing
The [ConnectionManager]
group SHOULD NOT contain keys
ObjectPath
or BusName
. If it does, they MUST
be ignored.
The object path and bus name are derivable from the connection manager's name, which is part of the filename, so these keys are redundant. They were required in very old versions of Telepathy.
For each protocol name proto that would be returned by
ListProtocols, the .manager file contains a group
headed [Protocol proto]
. For each parameter
p that would be returned by GetParameters(proto), the
.manager file contains a key param-p
with a value
consisting of a D-Bus signature (a single complete type), optionally
followed by a space and a space-separated list of flags. The supported
flags are:
required
, corresponding to
Conn_Mgr_Param_Flag_Requiredregister
, corresponding
to Conn_Mgr_Param_Flag_Registersecret
, corresponding
to Conn_Mgr_Param_Flag_Secretdbus-property
, corresponding
to Conn_Mgr_Param_Flag_DBus_PropertyThe group may also contain a key default-p
whose value is a string form of the default value for the parameter.
If this key exists, it sets the default, and also sets the flag
Conn_Mgr_Param_Flag_Has_Default. The default value is formatted
according to the D-Bus signature as follows:
Currently, no other D-Bus signatures are allowed to have default values,
but clients parsing the .manager file MUST ignore defaults
that they cannot parse, and treat them as if the
default-p
key was not present at all.
It is not required that a connection manager be able to support multiple protocols, or even multiple connections. When a connection is made, a service name where the connection object can be found is returned. A manager which can only make one connection may then remove itself from its well-known bus name, causing a new connection manager to be activated when somebody attempts to make a new connection.