Methods
GetContactInfo | (au: Contacts) | → | a{ua(sasas)}: ContactInfo | |
RefreshContactInfo | (au: Contacts) | → | nothing | |
RequestContactInfo | (u: Contact) | → | a(sasas): Contact_Info | |
SetContactInfo | (a(sasas): ContactInfo) | → | nothing |
Signals
ContactInfoChanged | (u: Contact, a(sasas): ContactInfo) |
Properties
ContactInfoFlags | u (Contact_Info_Flags) | Read only | |
SupportedFields | a(sasuu) (Field_Specs) | Read only |
Contact Attributes
org.freedesktop.Telepathy.Connection.Interface.ContactInfo/info | a(sasas) (Contact_Info_Field_List) |
Types
VCard_Field | Simple Type | s | |
VCard_Type_Parameter | Simple Type | s | |
Contact_Info_Flags | Flags | u | |
Contact_Info_Field_Flags | Flags | u | |
Contact_Info_Map | Mapping | a{ua(sasas)} | |
Contact_Info_Field | Struct | (sasas) | |
Field_Spec | Struct | (sasuu) |
Description
An interface for requesting information about a contact on a given connection. Information is represented as a list of Contact_Info_Fields forming a structured representation of a vCard (as defined by RFC 2426), using field names and semantics defined therein.
On some protocols, information about your contacts is pushed to you, with change notification; on others, like XMPP, the client must explicitly request the avatar, and has no way to tell whether it has changed without retrieving it in its entirety. This distinction is exposed by ContactInfoFlags containing the Push flag.
On protocols with the Push flag set, UIs can connect to ContactInfoChanged, call GetContactInfo once at login for the set of contacts they are interested in, and then be sure they will receive the latest contact info. On protocols like XMPP, clients can do the same, but will receive (at most) opportunistic updates if the info is retrieved for other reasons. Clients may call RequestContactInfo or RefreshContactInfo to force a contact's info to be updated, but MUST NOT do so unless this is either in response to direct user action, or to refresh their own cache after a number of days.
We don't want clients to accidentally cause a ridiculous amount of network traffic.
Methods
GetContactInfo (au: Contacts) → a{ua(sasas)}: ContactInfo
Parameters
- Contacts — au (Contact_Handle_List)
Returns
- ContactInfo — a{ua(sasas)} (Contact_Info_Map)
RefreshContactInfo (au: Contacts) → nothing
Parameters
- Contacts — au (Contact_Handle_List)
Possible Errors
- Disconnected
- Invalid Handle
RequestContactInfo (u: Contact) → a(sasas): Contact_Info
Parameters
- Contact — u (Contact_Handle)
Returns
- Contact_Info — a(sasas) (Contact_Info_Field_List)
Possible Errors
- Disconnected
- Network Error
- Invalid Handle
- Not Available
SetContactInfo (a(sasas): ContactInfo) → nothing
Parameters
- ContactInfo — a(sasas) (Contact_Info_Field_List)
Can_Set
, and may only be passed fields conforming to
SupportedFields.
Possible Errors
- Disconnected
- Network Error
- Permission Denied
- Not Available
- Not Implemented
- Invalid Argument
Signals
ContactInfoChanged (u: Contact, a(sasas): ContactInfo)
Parameters
- Contact — u (Contact_Handle)
- ContactInfo — a(sasas) (Contact_Info_Field_List)
Properties
ContactInfoFlags — u (Contact_Info_Flags)
An integer representing the bitwise-OR of flags on this connection.
This property MAY change, without change notification, at any time before the connection moves to status Connection_Status_Connected. It MUST NOT change after that point.
Some XMPP servers, like Facebook Chat, do not allow the vCard to be changed (and so would not have the Can_Set flag). Whether the user's server is one of these cannot necessarily be detected until quite late in the connection process.
SupportedFields — a(sasuu) (Field_Specs)
A list of field specifications describing the kinds of fields which may be passed to SetContactInfo. The empty list indicates that arbitrary vCard fields are permitted. This property SHOULD be the empty list, and be ignored by clients, if ContactInfoFlags does not contain the Can_Set flag.
For example, a protocol in which arbitrary vCards were stored as-is would set this property to the empty list. A protocol whose notion of contact information is one each of personal phone number, mobile phone number, location, email address and date of birth, with no attributes allowed on each piece of information, would set this property to (in Python-like syntax):
[ ('tel', ['type=home'], Parameters_Exact, 1), ('tel', ['type=cell'], Parameters_Exact, 1), ('adr', [], Parameters_Exact, 1), ('bday', [], Parameters_Exact, 1), ('email', ['type=internet'], Parameters_Exact, 1), ]
A protocol which allows users to specify up to four phone numbers,
which may be labelled as personal and/or mobile, would set this
property to
[ ('tel', ['type=home', 'type=cell'], 0, 4), ]
.
Studying existing IM protocols shows that in practice protocols allow either a very restricted set of fields (such as MSN, which seems to correspond roughly to the largest example above), or something mapping 1:1 to a large subset of vCard (such as XMPP's XEP-0054).
This property MAY change, without change notification, at any time before the connection moves to status Connection_Status_Connected. It MUST NOT change after that point.
Some XMPP servers, like Google Talk, only allow a small subset of the "vcard-temp" protocol. Whether the user's server is one of these cannot be detected until quite late in the connection process.
Contact Attributes
org.freedesktop.Telepathy.Connection.Interface.ContactInfo/info — a(sasas) (Contact_Info_Field_List)
The same value that would be returned by GetContactInfo for this contact. Omitted from the result if the contact's info is not known.
Types
VCard_Field — s
VCard_Type_Parameter — s
Contact_Info_Flags — u
- Can_Set (1)
- Push (2)
Contact_Info_Field_Flags — u
- Parameters_Exact (1)
If present, exactly the parameters indicated must be set on this field; in the case of an empty list of parameters, this implies that parameters may not be used.
If absent, and the list of allowed parameters is non-empty, any (possibly empty) subset of that list may be used.
If absent, and the list of allowed parameters is empty, any parameters may be used.
Contact_Info_Map — a{ua(sasas)}
- Handle — u (Contact_Handle)
- Contact_Info — a(sasas) (Contact_Info_Field_List)
Contact_Info_Field — (sasas)
Represents one piece of information about a contact, as modelled by a single vCard field. Of the fields defined in RFC 2426, common examples include:
- fn
- The contact's full name, formatted to their liking
- n
- The contact's full name, divided into five parts: family name, given name, additional names, honorific prefixes, and honorific suffixes
- org
- The contact's organisation, divided into the organization's name possibly followed by one or more organizational unit names.
- adr
- A street address for the contact, divided into seven components: post office box, extended address, street address, locality (e.g., city), region (e.g., state or province), the postal code, and the country name.
- label
- A free-form street address for the contact, formatted as a single value (with embedded newlines where necessary) suitable for printing on an address label
- tel
- A telephone number for the contact.
- An email address for the contact.
For example, the following vCard:
BEGIN:vCard VERSION:3.0 FN:Wee Ninja N;LANGUAGE=ja:Ninja;Wee;;;-san ORG:Collabora, Ltd.;Management Division;Human Resources\; Company Policy Enforcement ADR;TYPE=WORK,POSTAL,PARCEL:;;11 Kings Parade;Cambridge;Cambridgeshire ;CB2 1SJ;UK LABEL;TYPE=WORK,POSTAL,PARCEL:11 Kings Parade\nCambridge\nCambridgeshire\nUK\nCB2 1SJ TEL;TYPE=VOICE,WORK:+44 1223 362967, +44 7700 900753 EMAIL;TYPE=INTERNET,PREF:wee.ninja@collabora.co.uk EMAIL;TYPE=INTERNET:wee.ninja@example.com URL:http://www.thinkgeek.com/geektoys/plush/8823/ NICKNAME:HR Ninja,Enforcement Ninja END:vCard
would be represented by (in Python-like syntax):
[ ('fn', [], ['Wee Ninja']), ('n', ['language=ja'], ['Ninja', 'Wee', '', '', '-san']), ('org', [], ['Collabora, Ltd.', 'Management Division', 'Human Resources; Company Policy Enforcement']), ('adr', ['type=work','type=postal','type=parcel'], ['','','11 Kings Parade','Cambridge', 'Cambridgeshire','CB2 1SJ','UK']), ('label', ['type=work','type=postal','type=parcel'], ['''11 Kings Parade Cambridge Cambridgeshire UK CB2 1SJ''']), ('tel', ['type=voice','type=work'], ['+44 1223 362967']), ('tel', ['type=voice','type=work'], ['+44 7700 900753']), ('email', ['type=internet','type=pref'], ['wee.ninja@collabora.co.uk']), ('email', ['type=internet'], ['wee.ninja@example.com']), ('url', [], ['http://www.thinkgeek.com/geektoys/plush/8823/']), ('nickname', [], ['HR Ninja']), ('nickname', [], ['Enforcement Ninja']) ]
- Field_Name — s
- Parameters — as
- Field_Value — as
A list of vCard type parameters applicable to this field, with their values. The type parameter names, and any values that are case-insensitive in vCard, MUST be in lower case. For example, a contact's preferred home address would have parameters 'type=home' and 'type=pref'.
Characters which are required to be escaped in vCard type parameters should not be escaped in this list. For instance, a field "X-FOO;SEMICOLON=\;:bar" in a vCard would become ('x-foo', ['semicolon=;'], ['bar']) in this interface.
For unstructured vCard fields (such as 'fn', a formatted name field), a single-element array containing the field's value.
For structured fields (such as 'adr', an address field), an array corresponding to the semicolon-separated elements of the field (with empty strings for empty elements).
A vCard field with multiple comma-separated values, such as 'nickname', should be represented by several Contact_Info_Fields.
Characters which are required to be escaped in vCard values, such as semi-colons and newlines, should not be escaped in this list (e.g. if a value contains a newline, the data passed over D-Bus should contain a literal newline character).
Field_Spec — (sasuu)
- Name — s (VCard_Field)
- Parameters — as (VCard_Type_Parameter_List)
- Flags — u (Contact_Info_Field_Flags)
- Max — u