1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
<?xml version="1.0" ?>
<node name="/Client"
xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
<tp:copyright>Copyright © 2008-2009 Collabora Ltd.</tp:copyright>
<tp:copyright>Copyright © 2008-2009 Nokia Corporation</tp:copyright>
<tp:license xmlns="http://www.w3.org/1999/xhtml">
<p>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.</p>
<p>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.</p>
<p>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.</p>
</tp:license>
<interface name="org.freedesktop.Telepathy.Client">
<tp:added version="0.17.26">(as a stable interface)</tp:added>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Telepathy clients use connection managers, the channel dispatcher
and optionally the account manager to provide useful
functionality.</p>
<p>User interface processes are the obvious example of Telepathy
clients, but they can provide other functionality, such as
address-book synchronization.</p>
<p>Every running or activatable process with a well-known
name of the form org.freedesktop.Telepathy.Client.<em>clientname</em>
should be probed by the channel dispatcher to discover its
capabilities. Each client is either an <em>observer</em>, an
<em>approver</em>, a <em>channel handler</em>, or some combination
of these.</p>
<tp:rationale>
<p>Activatable services (those with a D-Bus <code>.service</code>
file) must be supported so that we can run clients
in response to channel creation.</p>
<p>Non-activatable services (those that do not register a D-Bus
<code>.service</code> file for their well-known name, but do
request it at runtime) must be supported so that we can have
programs that process channels, but only if they are already
running - for instance, a full-screen media centre
application might do this.</p>
</tp:rationale>
<p>The client name, <em>clientname</em>, MUST be a non-empty string of
ASCII digits, letters, dots and/or underscores, starting with a
letter, and without sets of two consecutive dots or a dot
followed by a digit. For non-activatable services, it MAY contain a
part that is generated per instance at runtime.</p>
<tp:rationale>
<p>If each of a client Foo's instances should be able to manipulate
channels separately, the instance with unique name
<code>:1.25</code> might request a well-known name like
<code>org.freedesktop.Telepathy.Client.Foo._1._25</code>.</p>
<p>(Note that well-known bus-name components may not start with a
digit, so o.f.T.Client.Foo.1.25 would not be acceptable.)</p>
</tp:rationale>
<p>Each Client MUST export an object whose object path may be
determined by replacing '.' with '/' in the well-known name and
prepending '/'. This object represents its API as a Telepathy
client; the channel dispatcher will call its methods and read
its properties when appropriate.</p>
<p>As an optimization, activatable clients SHOULD install a file
<code><a href="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">$XDG_DATA_DIRS</a>/telepathy/clients/<em>clientname</em>.client</code>
containing a cached version of its immutable properties,
so that for most clients, the channel dispatcher can
just read a file to discover capabilities, instead of
having to service-activate the client immediately in order to fetch
its read-only properties. However, the D-Bus API is canonical, and
the channel dispatcher MUST support clients without such a file.</p>
<p>Non-activatable clients MAY install a <code>.client</code> file,
but there's not much point in them doing so.</p>
<p>The .client files MUST contain UTF-8 text with the same syntax
as
<a href="http://standards.freedesktop.org/desktop-entry-spec/latest/">Desktop
Entry files</a> (although the allowed groups, keys and values differ).
Every <code>.client</code> file MUST contain a group whose name is
the name of this interface.</p>
<p>The groups, keys and values in the <code>.client</code> file are
defined by individual interfaces. Each interface that can usefully
cache information in the <code>.client</code> file SHOULD correspond
to a group with the same name.</p>
</tp:docstring>
<property name="Interfaces" tp:name-for-bindings="Interfaces"
type="as" access="read" tp:type="DBus_Interface[]">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>A list of the extra interfaces provided by this client.
This SHOULD include at least one of
<tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer</tp:dbus-ref>,
<tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Approver</tp:dbus-ref> or
<tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Handler</tp:dbus-ref>.</p>
<p>In the <code>.client</code> file, this is represented by key
"<code>Interfaces</code>" in the group named after this interface.
The value of the key is a list of interface names each followed by
a semicolon (so it always ends with a semicolon unless it is empty),
i.e. a key of type "strings" as described in the Desktop Entry
specification.</p>
</tp:docstring>
</property>
</interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
|
