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.

An interface for connections where it is possible to know what channel types may be requested before the request is made to the connection object. Each capability represents a commitment by the connection manager that it will ordinarily be able to create a channel when given a request with the given type and handle.

Capabilities pertain to particular contact handles, and represent activities such as having a text chat or a voice call with the user. The activities are represented by the D-Bus interface name of the channel type for that activity.

The generic capability flags are defined by Connection_Capability_Flags.

In addition, channel types may have type specific capability flags of their own, which are described in the documentation for each channel type.

This interface also provides for user interfaces notifying the connection manager of what capabilities to advertise for the user. This is done by using the AdvertiseCapabilities method, and deals with the interface names of channel types and the type specific flags pertaining to them which are implemented by available client processes.

Previously, this interface also expressed capabilities of the connection itself, indicating what sorts of channels could be requested (for instance, the ability to open chatroom lists or chatrooms). However, this was never very well-defined or consistent, and as far as we know it was never implemented correctly. This usage is now deprecated. Client implementations SHOULD use ContactCapabilities instead. Connection managers implementing Capabilities MUST implement ContactCapabilities too. The given channel type and handle can be given to RequestChannel to create a new channel of this type. The given contact can be invited to an existing channel of this type. A pair (channel type, type-specific flags) as passed to AdvertiseCapabilities on the Capabilities interface. A struct (contact handle, channel type, generic flags, type-specific flags) representing a capability posessed by a contact, as returned by GetCapabilities on the Capabilities interface. A struct (contact handle, channel type, old generic flags, new generic flags, old type-specific flags, new type-specific flags) representing a change to one of a contact's capabilities, as seen in the CapabilitiesChanged signal on the Capabilities interface. An array of structures containing:

a string channel type
a bitwise OR of type specific capability flags

An array of D-Bus interface names of channel types to remove An array of structures describing the current capabilities containing:

a string channel type
a bitwise OR of type specific capability flags

Used by user interfaces to indicate which channel types they are able to handle on this connection. Because these may be provided by different client processes, this method accepts channel types to add and remove from the set already advertised on this connection. The type of advertised capabilities (create versus invite) is protocol-dependent and hence cannot be set by the this method. In the case of a client adding an already advertised channel type but with new channel type specific flags, the connection manager should simply add the new flags to the set of advertised capabilities.

Upon a successful invocation of this method, the CapabilitiesChanged signal will be emitted for the user's own handle ( Connection.GetSelfHandle) by the connection manager to indicate the changes that have been made. This signal should also be monitored to ensure that the set is kept accurate - for example, a client may remove capabilities or type specific capability flags when it exits which are still provided by another client.

On connections managed by the ChannelDispatcher, this method SHOULD NOT be used by clients other than the ChannelDispatcher itself.

An array of structures containing:

an integer handle representing the contact
a string channel type
a bitwise OR of the contact's old generic capability flags
a bitwise OR of the contact's new generic capability flags
a bitwise OR of the contact's old type specific capability flags
a bitwise OR of the contact's new type specific capability flags

Announce that there has been a change of capabilities on the given handle.

If the handle is zero, the capabilities refer to the connection itself, in some poorly defined way. This usage is deprecated and clients should ignore it.

An array of contact handles for this connection.

This may include zero, which originally meant a query for capabilities available on the connection itself. This usage is deprecated; clients SHOULD NOT do this, and connection managers SHOULD proceed as though zero had not been present in this list.

An array of structures containing:

an integer handle representing the contact
a string channel type
a bitwise OR of generic capability flags for the type
a bitwise OR of type specific capability flags for the type

Returns an array of capabilities for the given contact handles.

The handle does not represent a contact and is not zero

The same structs that would be returned by GetCapabilities (all of them will redundantly have the contact's handle as the first member). Omitted from the result if the contact's capabilities are not known; present in the result as an empty array if the contact is known to have no capabilities at all.