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 channel's type. This cannot change once the channel has been created.

The GetAll method lets clients retrieve all properties in one round-trip, which is desirable.

When requesting a channel, the request MUST specify a channel type, and the request MUST fail if the specified channel type cannot be supplied.

Common sense.

Extra interfaces provided by this channel. This SHOULD NOT include the channel type and the Channel interface itself, and cannot change once the channel has been created.

When requesting a channel with a particular value for this property, the request must fail without side-effects unless the connection manager expects to be able to provide a channel whose interfaces include at least the interfaces requested.

The handle (a representation for the identifier) of the contact, chatroom, etc. with which this handle communicates. Its type is given by the TargetHandleType property.

This is fixed for the lifetime of the channel, so channels which could potentially be used to communicate with multiple contacts, and do not have an identity of their own (such as a Handle_Type_Room handle), must have TargetHandleType set to Handle_Type_None and TargetHandle set to 0.

Unlike in the telepathy-spec 0.16 API, there is no particular uniqueness guarantee - there can be many channels with the same (channel type, handle type, handle) tuple. This is necessary to support conversation threads in XMPP and SIP, for example.

If this is present in a channel request, it must be nonzero, TargetHandleType MUST be present and not Handle_Type_None, and TargetID MUST NOT be present. Properties from Addressing1 MUST NOT be present.

The channel that satisfies the request MUST either:

have the specified TargetHandle property; or
have TargetHandleType = Handle_Type_None, TargetHandle = 0, and be configured such that it could communicate with the specified handle in some other way (e.g. have the requested contact handle in its Group interface)

The string that would result from inspecting the TargetHandle property (i.e. the identifier in the IM protocol of the contact, room, etc. with which this channel communicates), or the empty string if the TargetHandle is 0.

If this is present in a channel request, TargetHandleType MUST be present and not Handle_Type_None, and TargetHandle MUST NOT be present. Properties from Addressing1 MUST NOT be present.The request MUST fail with error InvalidHandle, without side-effects, if the requested TargetID is invalid.

The returned channel must be related to the handle corresponding to the given identifier, in the same way as if TargetHandle had been part of the request instead.

Requesting channels with a string identifier allows the channel dispatcher to accept a channel request for an account that is not yet connected (and thus has no valid handles), bring the account online, and pass on the same parameters to the new connection's CreateChannel method.

The type of TargetHandle.

If this is omitted from a channel request, connection managers SHOULD treat this as equivalent to Handle_Type_None.

If this is omitted or is Handle_Type_None, TargetHandle and TargetID MUST be omitted from the request.

Request that the channel be closed. This is not the case until the Closed signal has been emitted, and depending on the connection manager this may simply remove you from the channel on the server, rather than causing it to stop existing entirely. Some channels such as contact list channels may not be closed.

This channel may never be closed, e.g. a contact list This channel is not currently in a state where it can be closed, e.g. a non-empty user-defined contact group

Emitted when the channel has been closed. Method calls on the channel are no longer valid after this signal has been emitted, and the connection manager may then remove the object from the bus at any point. (as stable API)

True if this channel was created in response to a local request, such as a call to Connection.Interface.Requests.CreateChannel.

The idea of this property is to distinguish between "incoming" and "outgoing" channels, in a way that doesn't break down when considering special cases like contact lists that are automatically created on connection to the server, or chatrooms that an IRC proxy/bouncer like irssi-proxy or bip was already in.

The reason we want to make that distinction is that UIs for things that the user explicitly requested should start up automatically, whereas for incoming messages and VoIP calls we should first ask the user whether they want to open the messaging UI or accept the call.

If the channel was not explicitly requested (even if it was created as a side-effect of a call to one of those functions, e.g. because joining a Tube in a MUC context on XMPP implies joining that MUC), then this property is false.

It does not make sense for this property to be in channel requests—it will always be true for channels returned by CreateChannel, and callers of EnsureChannel cannot control whether an existing channel was originally requested locally—so it MUST NOT be accepted.

(as stable API)

The contact who initiated the channel; for instance, the contact who invited the local user to a chatroom, or the contact who initiated a call.

This does not necessarily represent the contact who created the underlying protocol-level construct. For instance, if Rob creates a chatroom, Will joins that chatroom, and Will invites Simon to join it, then Simon will see Will as the InitiatorHandle of the channel representing the chatroom.

The room creator is generally a less useful piece of information than the inviter, is less likely to be available at invitation time (i.e. can't necessarily be an immutable property), and is less likely to be available at all. The creator of a chatroom is not currently available via Telepathy; if added in future, it is likely to be made available as a property on the Chatroom interface (bug 23151).

For channels requested by the local user, this MUST be the value of Connection.SelfHandle at the time the channel was created (i.e. not a channel-specific handle).

On some protocols, the SelfHandle may change (as signalled by Connection.SelfContactChanged), but this property is immutable. Hence, locally-requested channels' InitiatorHandle and InitiatorID may not match the current SelfHandle; Requested can be used to determine whether the channel was created locally.

For channels requested by a remote user, this MUST be their handle. If unavailable or not applicable, this MUST be 0 (for instance, contact lists are not really initiated by anyone in particular, and it's easy to imagine a protocol where chatroom invitations can be anonymous).

For channels with the Group1 interface, this SHOULD be the same contact who is signalled as the "Actor" causing the self-handle to be placed in the local-pending set.

This SHOULD NOT be a channel-specific handle, if possible.

It does not make sense for this property to be in channel requests - the initiator will always be the local user - so it MUST NOT be accepted.

(as stable API)

The string that would result from inspecting the InitiatorHandle property (i.e. the initiator's identifier in the IM protocol).

It does not make sense for this property to be in channel requests - the initiator will always be the local user - so it MUST NOT be accepted.

All communication in the Telepathy framework is carried out via channel objects which are created and managed by connections. This interface must be implemented by all channel objects, along with one single channel type, such as Channel.Type.Text which represents a channel over which textual messages are sent and received.

Each Channel's object path MUST start with the object path of its associated Connection, followed by '/'. There MAY be any number of additional object-path components, which clients MUST NOT attempt to parse.

This ensures that Channel object paths are unique, even between Connections and CMs, because Connection object paths are guaranteed-unique via their link to the well-known bus name.

If all connection managers in use are known to comply with at least spec version 0.17.10, then the Connection's object path can even be determined from the Channel's without any additional information, by taking the first 7 components.

Each channel has a number of immutable properties (which cannot vary after the channel has been announced with NewChannels), provided to clients in the ObserveChannels, AddDispatchOperation and HandleChannels methods to permit immediate identification of the channel. This interface contains immutable properties common to all channels. In brief:

ChannelType specifies the kind of communication carried out on this channel;
TargetHandleType, TargetHandle and TargetID specify the entity with which this channel communicates, such as the other party in a 1-1 call, or the name of a multi-user chat room;
InitiatorHandle and InitiatorID specify who created this channel;
Requested indicates whether the local user requested this channel, or whether it is an incoming call, a text conversation started by a remote contact, a chatroom invitation, etc.

Other optional Interfaces can be implemented to indicate other available functionality, such as Channel.Interface.Group1 if the channel contains a number of contacts, Channel.Interface.Password1 to indicate that a channel may have a password set to require entry, and Channel.Interface.ChatState1 for typing notifications. The interfaces implemented may not vary after the channel has been created. These other interfaces (along with the interface named by ChannelType) may themselves specify immutable properties to be announced up-front along with the properties on this interface.

Some channels are “anonymous”, with TargetHandleType set to None, which indicates that the channel is defined by some other properties. For instance, transient ad-hoc chat rooms may be defined only by their members (as visible through the Group1 interface), and ContactSearch1 channels represent a single search attempt for a particular Server.

Specific connection manager implementations may implement channel types and interfaces which are not contained within this specification in order to support further functionality. To aid interoperability between client and connection manager implementations, the interfaces specified here should be used wherever applicable, and new interfaces made protocol-independent wherever possible. Because of the potential for 3rd party interfaces adding methods or signals with conflicting names, the D-Bus interface names should always be used to invoke methods and bind signals.

Previously we guaranteed that, for any handle type other than Handle_Type_None, and for any channel type and any handle, there would be no more than one channel with that combination of channel type, handle type and handle. This guarantee has now been removed in order to accommodate features like message threads. Previously we did not explicitly guarantee that Channels' object paths had the Connection's object path as a prefix. Deprecated methods (GetChannelType, GetHandle, and GetInterfaces) have been removed from this interface.