Methods
| SetPresence | (s: Status, s: Status_Message) | → | nothing |
Signals
| PresencesChanged | (a{u(uss)}: Presence) |
Properties
| Statuses | a{s(ubb)} (Status_Spec_Map) | Read only | ||
| MaximumStatusMessageLength | u | Read only |
Contact Attributes
| im.telepathy.v1.Connection.Interface.Presence1/presence | (uss) (Presence) |
Types
| Connection_Presence_Type | Enum | u | |
| Access_Control_Type | Enum | u | |
| Contact_Presence_Map | Mapping | a{u(uss)} | |
| Status_Spec_Map | Mapping | a{s(ubb)} | |
| Presence | Struct | (uss) | |
| Status_Spec | Struct | (ubb) | |
| Access_Control | Struct | (uv) |
Description
This interface is for services which have a concept of presence which can be published for yourself and monitored on your contacts.
Presence on an individual (yourself or one of your contacts) is modelled as a status and a status message. Valid statuses are defined per connection, and a list of those that can be set on youself can be obtained from the Statuses property.
Each status has an arbitrary string identifier which should have an agreed meaning between the connection manager and any client which is expected to make use of it. The following well-known values should be used where possible to allow clients to identify common choices:
| Status identifier | Connection_Presence_Type | Remarks |
|---|---|---|
"available" |
Available | |
"chat" |
Available | Actively interested in chatting, as opposed to merely available. |
"pstn" |
Available | This contact is actually a phone number, not an IM account. As
such, the contact is conceptually always available, but not in the
same way that a contact can set their IM status to “available”.
It does not make sense to allow the user to set this status on
herself; hence, on protocols where this status is supported, its
entry in Statuses SHOULD have
May_Set_On_Self set to False. |
"away" |
Away | |
"brb" |
Away | Be Right Back (a more specific form of Away) |
"busy" |
Busy | |
"dnd" |
Busy | Do Not Disturb (a more specific form of Busy) |
"xa" |
Extended_Away | Extended Away |
"hidden" |
Hidden | Also known as "Invisible" or "Appear Offline" |
"offline" |
Offline | |
"unknown" |
Unknown | special, see below |
"error" |
Error | special, see below |
As well as these well-known status identifiers, every status also has a numerical type value chosen from Connection_Presence_Type which can be used by the client to classify even unknown statuses into different fundamental types.
These numerical types exist so that even if a client does not understand the string identifier being used, and hence cannot present the presence to the user to set on themselves, it may display an approximation of the presence if it is set on a contact.
As well as the normal status identifiers, there are two special ones that may be present: 'unknown' with type Unknown and 'error' with type Error. 'unknown' indicates that it is impossible to determine the presence of a contact at this time, for example because it's not on the 'subscribe' list and the protocol only allows one to determine the presence of contacts you're subscribed to. 'error' indicates that there was a failure in determining the status of a contact.
If the connection has a 'subscribe' contact list, PresencesChanged signals should be emitted to indicate changes of contacts on this list, and should also be emitted for changes in your own presence. Depending on the protocol, the signal may also be emitted for others such as people with whom you are communicating, and any user interface should be updated accordingly.
Methods
SetPresence (s: Status, s: Status_Message) → nothing
Parameters
- Status — s
- Status_Message — s
The string identifier of the desired status. Possible status identifiers are defined in the Statuses property.
Clients MUST NOT set a status whose string value they do not recognise, even if its presence type in Statuses matches what the user requested.
Rationale:
Suppose a protocol has statuses that include 'phone' (of type BUSY) and 'in-a-meeting' (of type BUSY), but there is no generic 'busy' status.
If the user requests "Busy" status from a menu, a client author might be tempted to pick an arbitrary status that has type BUSY. However, on this protocol, neither of the choices would be appropriate, and incorrect information about the user would be conveyed.
Statuses whose Connection_Presence_Type is Offline, Error or Unknown MUST NOT be passed to this function. Connection managers SHOULD reject these statuses.
Rationale:
To go offline, call Disconnect instead. The "error" and "unknown" statuses make no sense.
Request that the presence status and status message are published for the connection. Changes will be indicated by PresencesChanged signals being emitted.
This method may be called on a newly-created connection while it is still in the DISCONNECTED state, to request that when the connection connects, it will do so with the selected status.
In DISCONNECTED state the Statuses property will indicate which statuses are allowed to be set while DISCONNECTED (none, if the Connection Manager doesn't allow this). This value MUST NOT be cached, as the set of allowed presences might change upon connecting.
Possible Errors
- Network Error
- Invalid Argument
- Not Available
Signals
PresencesChanged (a{u(uss)}: Presence)
Parameters
- Presence — a{u(uss)} (Contact_Presence_Map)
Properties
Statuses — a{s(ubb)} (Status_Spec_Map)
A dictionary where the keys are the presence statuses that are available on this connection, and the values are the corresponding presence types.
While the connection is in the DISCONNECTED state, it contains the set of presence statuses allowed to be set before connecting. The connection manager will attempt to set the appropriate status when the connection becomes connected, but cannot necessarily guarantee it. The available statuses cannot change until the connection status changes, so there is no change notification.
While the connection is in the CONNECTED state, this property contains the set of presence statuses which are actually available on this protocol. This set is constant for the remaining lifetime of the connection, so again, there is no change notification.
While the connection is in the CONNECTING state, the value of this property is undefined and SHOULD NOT be used. It can change at any time without notification (in particular, any cached values from when the connection was in the DISCONNECTED or CONNECTING state MUST NOT be assumed to still be correct when the state has become CONNECTED).
This property MUST include the special statuses "unknown" and "error" if and only if the connection manager can emit them as a contact's status.
Rationale:
MaximumStatusMessageLength — u
The maximum length in characters for any individual status message, or 0 if there is no limit.
While the connection is in the DISCONNECTED state, this property will be 0. The connection manager will attempt to set the appropriate value when the connection becomes connected, but cannot necessarily guarantee it. The maximum length cannot change until the connection status changes, so there is no change notification.
While the connection is in the CONNECTED state, this property contains the maximum length in characters for any individual status message which is actually allowed on this protocol. This value is constant for the remaining lifetime of the connection, so again, there is no change notification.
While the connection is in the CONNECTING state, the value of this property is undefined and SHOULD NOT be used. It can change at any time without notification (in particular, any cached values from when the connection was in the DISCONNECTED or CONNECTING state MUST NOT be assumed to still be correct when the state has become CONNECTED).
If a message passed to SetPresence is longer than allowed by this property, the connection manager MUST truncate the supplied message; when emitting PresencesChanged, the truncated version of the message MUST be used.
Rationale:
Some XMPP servers, like Google Talk, define a maximum length for status messages. Whether the user's server is one of these cannot be detected until quite late in the connection process.
Contact Attributes
im.telepathy.v1.Connection.Interface.Presence1/presence — (uss) (Presence)
The contact's presence.
The presence is likely to be (Unknown, "unknown", "") unless subscribe contact attribute is Yes, or the local user can temporarily see their presence for some other reason (for instance, on XMPP, contacts seen in chatrooms will temporarily have available presence).
Always present with some value if information if the Presence interface was requested
Types
Connection_Presence_Type — u
- Unset (0)
- Offline (1)
- Available (2)
- Away (3)
- Extended_Away (4)
- Hidden (5)
- Busy (6)
- Unknown (7)
- Error (8)
Access_Control_Type — u
A type for communication access control. These control policies are used in CommunicationPolicy1 and in rich presence interfaces such as Location1.
- Whitelist (0)
- Publish_List (1)
- Group (2)
- Open (3)
- Subscribe_Or_Publish_List (4)
- Closed (5)
- Not_Understood (6)
Only allow contacts that are in a certain whitelist.
The associated variant
in Access_Control is a list of
Contact_Handle representing
the whitelist, with signature au.
Only allow contacts that are in a certain user-defined group, as configured by the ContactGroups1 interface.
The associated variant in Access_Control is a string (D-Bus type 's'), the name of a contact group.
The access control rule is too complex to be represented in the current Telepathy API. The associated variant is meaningless. Setting this mode is never valid; the connection manager MUST raise an error if this is attempted.
Rationale:
The associated variant in Access_Control is ignored.
Contact_Presence_Map — a{u(uss)}
- Contact — u (Contact_Handle)
- Presence — (uss) (Presence)
Status_Spec_Map — a{s(ubb)}
- Identifier — s
- Spec — (ubb) (Status_Spec)
Presence — (uss)
- Type — u (Connection_Presence_Type)
- Status — s
- Status_Message — s
The user-defined status message, e.g. "Back soon!".
Clients SHOULD set the status message for the local user to the empty string, unless the user has actually provided a specific message (i.e. one that conveys more information than the Status).
User interfaces SHOULD regard an empty status message as unset, and MAY replace it with a localized string corresponding to the Status or Type.
Rationale:
Status_Spec — (ubb)
- Type — u (Connection_Presence_Type)
- May_Set_On_Self — b
- Can_Have_Message — b
Rationale:
Access_Control — (uv)
An access control mode for extended presence items like geolocation. This type isn't actually used by the Presence interface, but it's included here so it can be referenced by rich presence interfaces.
- Type — u (Access_Control_Type)
- Detail — v