[telepathy-mission-control/master] Update to telepathy-spec 0.17.23 ChannelDispatcher interfaces
Simon McVittie
simon.mcvittie at collabora.co.uk
Tue Apr 21 09:02:33 PDT 2009
Also enable Client.Interface.Requests in libmcclient.
---
libmcclient/client.xml | 1 +
src/client.xml | 2 +-
src/mcd-dispatcher.c | 54 +++-----
test/twisted/account-requests/cancel.py | 9 +-
test/twisted/account-requests/create-text.py | 9 +-
.../delete-account-during-request.py | 8 +-
test/twisted/constants.py | 17 +--
test/twisted/dispatcher/already-has-channel.py | 4 +-
test/twisted/dispatcher/cancel.py | 21 ++--
test/twisted/dispatcher/create-text.py | 13 +-
test/twisted/dispatcher/dispatch-text.py | 4 +-
test/twisted/dispatcher/exploding-bundles.py | 4 +-
test/twisted/dispatcher/fdo-21034.py | 2 +-
test/twisted/dispatcher/lose-text.py | 4 +-
test/twisted/fakeclient.py | 8 +-
test/twisted/mctest.py | 2 +-
xml/Channel_Dispatch_Operation.xml | 152 ++++++++++++++------
xml/Channel_Dispatcher.xml | 89 +++++-------
...Channel_Dispatcher_Interface_Operation_List.xml | 19 ++--
xml/Channel_Request.xml | 6 +-
xml/Client.xml | 10 +-
xml/Client_Approver.xml | 48 ++++---
xml/Client_Handler.xml | 14 +-
...ification.xml => Client_Interface_Requests.xml} | 28 ++--
xml/Client_Observer.xml | 30 ++--
xml/Makefile.am | 2 +-
xml/nmc5.xml | 2 +-
27 files changed, 297 insertions(+), 265 deletions(-)
rename xml/{Client_Handler_Interface_Request_Notification.xml => Client_Interface_Requests.xml} (90%)
diff --git a/libmcclient/client.xml b/libmcclient/client.xml
index 93bb711..95a5b35 100644
--- a/libmcclient/client.xml
+++ b/libmcclient/client.xml
@@ -5,6 +5,7 @@
<xi:include href="../xml/Client.xml"/>
<xi:include href="../xml/Client_Approver.xml"/>
<xi:include href="../xml/Client_Handler.xml"/>
+<xi:include href="../xml/Client_Interface_Requests.xml"/>
<xi:include href="../xml/Client_Observer.xml"/>
</tp:spec>
diff --git a/src/client.xml b/src/client.xml
index e8d3b43..95a5b35 100644
--- a/src/client.xml
+++ b/src/client.xml
@@ -5,7 +5,7 @@
<xi:include href="../xml/Client.xml"/>
<xi:include href="../xml/Client_Approver.xml"/>
<xi:include href="../xml/Client_Handler.xml"/>
-<xi:include href="../xml/Client_Handler_Interface_Request_Notification.xml"/>
+<xi:include href="../xml/Client_Interface_Requests.xml"/>
<xi:include href="../xml/Client_Observer.xml"/>
</tp:spec>
diff --git a/src/mcd-dispatcher.c b/src/mcd-dispatcher.c
index 09f3e44..b8b82d8 100644
--- a/src/mcd-dispatcher.c
+++ b/src/mcd-dispatcher.c
@@ -144,7 +144,7 @@ typedef enum
MCD_CLIENT_APPROVER = 0x1,
MCD_CLIENT_HANDLER = 0x2,
MCD_CLIENT_OBSERVER = 0x4,
- MCD_CLIENT_HANDLER_REQUEST_NOTIFICATION = 0x8,
+ MCD_CLIENT_INTERFACE_REQUESTS = 0x8,
} McdClientInterface;
typedef struct _McdClient
@@ -183,23 +183,8 @@ typedef struct _McdClient
GList *observer_filters;
} McdClient;
-/* The same defines as MC_IFACE_CLIENT* from interfaces.h but without the
- * ".DRAFT" suffix, to be used in .client files. Once the interfaces are
- * undrafted, theses defines must be removed.
- */
-#define MC_FILE_IFACE_CLIENT \
- "org.freedesktop.Telepathy.Client"
-#define MC_FILE_IFACE_CLIENT_APPROVER \
- "org.freedesktop.Telepathy.Client.Approver"
-#define MC_FILE_IFACE_CLIENT_HANDLER \
- "org.freedesktop.Telepathy.Client.Handler"
-#define MC_FILE_IFACE_CLIENT_HANDLER_INTERFACE_REQUEST_NOTIFICATION \
- "org.freedesktop.Telepathy.Client.Handler.Interface.RequestNotification"
-#define MC_FILE_IFACE_CLIENT_OBSERVER \
- "org.freedesktop.Telepathy.Client.Observer"
-
/* Analogous to TP_CM_*_BASE */
-#define MC_CLIENT_BUS_NAME_BASE MC_FILE_IFACE_CLIENT "."
+#define MC_CLIENT_BUS_NAME_BASE MC_IFACE_CLIENT "."
#define MC_CLIENT_OBJECT_PATH_BASE "/org/freedesktop/Telepathy/Client/"
struct _McdDispatcherPrivate
@@ -2080,9 +2065,8 @@ client_add_interface_by_id (McdClient *client)
if (client->interfaces & MCD_CLIENT_HANDLER)
tp_proxy_add_interface_by_id (client->proxy,
MC_IFACE_QUARK_CLIENT_HANDLER);
- if (client->interfaces & MCD_CLIENT_HANDLER_REQUEST_NOTIFICATION)
- tp_proxy_add_interface_by_id (client->proxy,
- MC_IFACE_QUARK_CLIENT_HANDLER_INTERFACE_REQUEST_NOTIFICATION);
+ if (client->interfaces & MCD_CLIENT_INTERFACE_REQUESTS)
+ tp_proxy_add_interface_by_id (client->proxy, MC_IFACE_QUARK_CLIENT_INTERFACE_REQUESTS);
if (client->interfaces & MCD_CLIENT_OBSERVER)
tp_proxy_add_interface_by_id (client->proxy,
MC_IFACE_QUARK_CLIENT_OBSERVER);
@@ -2108,8 +2092,8 @@ get_interfaces_cb (TpProxy *proxy,
client->interfaces |= MCD_CLIENT_APPROVER;
if (strcmp (*arr, MC_IFACE_CLIENT_HANDLER) == 0)
client->interfaces |= MCD_CLIENT_HANDLER;
- if (strcmp (*arr, MC_IFACE_CLIENT_HANDLER_INTERFACE_REQUEST_NOTIFICATION) == 0)
- client->interfaces |= MCD_CLIENT_HANDLER_REQUEST_NOTIFICATION;
+ if (strcmp (*arr, MC_IFACE_CLIENT_INTERFACE_REQUESTS) == 0)
+ client->interfaces |= MCD_CLIENT_INTERFACE_REQUESTS;
if (strcmp (*arr, MC_IFACE_CLIENT_OBSERVER) == 0)
client->interfaces |= MCD_CLIENT_OBSERVER;
arr++;
@@ -2164,20 +2148,20 @@ parse_client_file (McdClient *client, GKeyFile *file)
guint i;
gsize len = 0;
- iface_names = g_key_file_get_string_list (file, MC_FILE_IFACE_CLIENT,
+ iface_names = g_key_file_get_string_list (file, MC_IFACE_CLIENT,
"Interfaces", 0, NULL);
if (!iface_names)
return;
for (i = 0; iface_names[i] != NULL; i++)
{
- if (strcmp (iface_names[i], MC_FILE_IFACE_CLIENT_APPROVER) == 0)
+ if (strcmp (iface_names[i], MC_IFACE_CLIENT_APPROVER) == 0)
client->interfaces |= MCD_CLIENT_APPROVER;
- else if (strcmp (iface_names[i], MC_FILE_IFACE_CLIENT_HANDLER) == 0)
+ else if (strcmp (iface_names[i], MC_IFACE_CLIENT_HANDLER) == 0)
client->interfaces |= MCD_CLIENT_HANDLER;
- else if (strcmp (iface_names[i], MC_FILE_IFACE_CLIENT_HANDLER_INTERFACE_REQUEST_NOTIFICATION) == 0)
- client->interfaces |= MCD_CLIENT_HANDLER_REQUEST_NOTIFICATION;
- else if (strcmp (iface_names[i], MC_FILE_IFACE_CLIENT_OBSERVER) == 0)
+ else if (strcmp (iface_names[i], MC_IFACE_CLIENT_INTERFACE_REQUESTS) == 0)
+ client->interfaces |= MCD_CLIENT_INTERFACE_REQUESTS;
+ else if (strcmp (iface_names[i], MC_IFACE_CLIENT_OBSERVER) == 0)
client->interfaces |= MCD_CLIENT_OBSERVER;
}
g_strfreev (iface_names);
@@ -2187,7 +2171,7 @@ parse_client_file (McdClient *client, GKeyFile *file)
for (i = 0; i < len; i++)
{
if (client->interfaces & MCD_CLIENT_APPROVER &&
- g_str_has_prefix (groups[i], MC_FILE_IFACE_CLIENT_APPROVER
+ g_str_has_prefix (groups[i], MC_IFACE_CLIENT_APPROVER
".ApproverChannelFilter "))
{
client->approver_filters =
@@ -2195,7 +2179,7 @@ parse_client_file (McdClient *client, GKeyFile *file)
parse_client_filter (file, groups[i]));
}
else if (client->interfaces & MCD_CLIENT_HANDLER &&
- g_str_has_prefix (groups[i], MC_FILE_IFACE_CLIENT_HANDLER
+ g_str_has_prefix (groups[i], MC_IFACE_CLIENT_HANDLER
".HandlerChannelFilter "))
{
client->handler_filters =
@@ -2203,7 +2187,7 @@ parse_client_file (McdClient *client, GKeyFile *file)
parse_client_filter (file, groups[i]));
}
else if (client->interfaces & MCD_CLIENT_OBSERVER &&
- g_str_has_prefix (groups[i], MC_FILE_IFACE_CLIENT_OBSERVER
+ g_str_has_prefix (groups[i], MC_IFACE_CLIENT_OBSERVER
".ObserverChannelFilter "))
{
client->observer_filters =
@@ -2215,7 +2199,7 @@ parse_client_file (McdClient *client, GKeyFile *file)
/* Other client options */
client->bypass_approver =
- g_key_file_get_boolean (file, MC_FILE_IFACE_CLIENT_HANDLER,
+ g_key_file_get_boolean (file, MC_IFACE_CLIENT_HANDLER,
"BypassApproval", NULL);
}
@@ -3032,7 +3016,7 @@ on_request_status_changed (McdChannel *channel, McdChannelStatus status,
error = mcd_channel_get_error (channel);
err_string = _mcd_build_error_string (error);
/* no callback, as we don't really care */
- mc_cli_client_handler_interface_request_notification_call_remove_request
+ mc_cli_client_interface_requests_call_remove_request
(rrd->handler, -1, rrd->request_path, err_string, error->message,
NULL, NULL, NULL, NULL);
g_free (err_string);
@@ -3084,7 +3068,7 @@ _mcd_dispatcher_add_request (McdDispatcher *dispatcher, McdAccount *account,
return;
}
- if (!(handler->interfaces & MCD_CLIENT_HANDLER_REQUEST_NOTIFICATION))
+ if (!(handler->interfaces & MCD_CLIENT_INTERFACE_REQUESTS))
{
DEBUG ("Default handler %s for request %s doesn't want AddRequest",
handler->name, _mcd_channel_get_request_path (channel));
@@ -3128,7 +3112,7 @@ _mcd_dispatcher_add_request (McdDispatcher *dispatcher, McdAccount *account,
g_hash_table_insert (properties, "org.freedesktop.Telepathy.ChannelRequest"
".PreferredHandler", &v_preferred_handler);
- mc_cli_client_handler_interface_request_notification_call_add_request (
+ mc_cli_client_interface_requests_call_add_request (
handler->proxy, -1,
_mcd_channel_get_request_path (channel), properties,
NULL, NULL, NULL, NULL);
diff --git a/test/twisted/account-requests/cancel.py b/test/twisted/account-requests/cancel.py
index e605607..9adeffd 100644
--- a/test/twisted/account-requests/cancel.py
+++ b/test/twisted/account-requests/cancel.py
@@ -79,10 +79,7 @@ def test(q, bus, mc):
request_path = ret.value[0]
cr = bus.get_object(cs.AM, request_path)
- # FIXME: MC gives CR properties to clients without .DRAFT, but the
- # CR itself is really still .DRAFT
- request_props = cr.GetAll(cs.CR + '.DRAFT',
- dbus_interface=cs.PROPERTIES_IFACE)
+ request_props = cr.GetAll(cs.CR, dbus_interface=cs.PROPERTIES_IFACE)
assert request_props['Account'] == account.object_path
assert request_props['Requests'] == [request]
assert request_props['UserActionTime'] == user_action_time
@@ -93,7 +90,7 @@ def test(q, bus, mc):
# call precedes this
e = q.expect('dbus-method-call', handled=False,
- interface=cs.HANDLER_IFACE_REQUEST_NOTIFICATION, method='AddRequest',
+ interface=cs.CLIENT_IFACE_REQUESTS, method='AddRequest',
path=client.object_path)
assert e.args[0] == request_path
q.dbus_return(e.message, signature='')
@@ -123,7 +120,7 @@ def test(q, bus, mc):
EventPattern('dbus-signal', path=account.object_path,
interface=cs.ACCOUNT_IFACE_NOKIA_REQUESTS, signal='Failed'),
EventPattern('dbus-signal', path=request_path,
- interface=cs.CR + '.DRAFT', signal='Failed'),
+ interface=cs.CR, signal='Failed'),
EventPattern('dbus-method-call', path=channel.object_path,
interface=cs.CHANNEL, method='Close', handled=True),
)
diff --git a/test/twisted/account-requests/create-text.py b/test/twisted/account-requests/create-text.py
index 15c23e8..1b8bee0 100644
--- a/test/twisted/account-requests/create-text.py
+++ b/test/twisted/account-requests/create-text.py
@@ -86,10 +86,7 @@ def test_channel_creation(q, bus, account, client, conn, ensure):
request_path = ret.value[0]
cr = bus.get_object(cs.AM, request_path)
- # FIXME: MC gives CR properties to clients without .DRAFT, but the
- # CR itself is really still .DRAFT
- request_props = cr.GetAll(cs.CR + '.DRAFT',
- dbus_interface=cs.PROPERTIES_IFACE)
+ request_props = cr.GetAll(cs.CR, dbus_interface=cs.PROPERTIES_IFACE)
assert request_props['Account'] == account.object_path
assert request_props['Requests'] == [request]
assert request_props['UserActionTime'] == user_action_time
@@ -100,7 +97,7 @@ def test_channel_creation(q, bus, account, client, conn, ensure):
# call precedes this
e = q.expect('dbus-method-call', handled=False,
- interface=cs.HANDLER_IFACE_REQUEST_NOTIFICATION, method='AddRequest',
+ interface=cs.CLIENT_IFACE_REQUESTS, method='AddRequest',
path=client.object_path)
assert e.args[0] == request_path
request_props = e.args[1]
@@ -173,7 +170,7 @@ def test_channel_creation(q, bus, account, client, conn, ensure):
interface=cs.ACCOUNT_IFACE_NOKIA_REQUESTS, signal='Succeeded',
args=[request_path]),
EventPattern('dbus-signal', path=request_path,
- interface=cs.CR + '.DRAFT', signal='Succeeded'),
+ interface=cs.CR, signal='Succeeded'),
)
# Close the channel
diff --git a/test/twisted/account-requests/delete-account-during-request.py b/test/twisted/account-requests/delete-account-during-request.py
index 7c1afa6..acf6b23 100644
--- a/test/twisted/account-requests/delete-account-during-request.py
+++ b/test/twisted/account-requests/delete-account-during-request.py
@@ -74,7 +74,7 @@ def test(q, bus, mc):
request_path = ret.value[0]
e = q.expect('dbus-method-call', handled=False,
- interface=cs.HANDLER_IFACE_REQUEST_NOTIFICATION, method='AddRequest',
+ interface=cs.CLIENT_IFACE_REQUESTS, method='AddRequest',
path=client.object_path)
assert e.args[0] == request_path
@@ -101,7 +101,7 @@ def test(q, bus, mc):
# You know that request I told you about? Not going to happen.
remove_request = q.expect('dbus-method-call',
- interface=cs.HANDLER_IFACE_REQUEST_NOTIFICATION,
+ interface=cs.CLIENT_IFACE_REQUESTS,
method='RemoveRequest',
handled=False)
assert remove_request.args[0] == request_path
@@ -111,9 +111,7 @@ def test(q, bus, mc):
q.expect_many(
EventPattern('dbus-signal',
- path=request_path,
- interface=cs.CR + '.DRAFT',
- signal='Failed',
+ path=request_path, interface=cs.CR, signal='Failed',
args=remove_request.args[1:]),
EventPattern('dbus-signal',
path=account.object_path,
diff --git a/test/twisted/constants.py b/test/twisted/constants.py
index 65e3505..5794f0a 100644
--- a/test/twisted/constants.py
+++ b/test/twisted/constants.py
@@ -119,12 +119,12 @@ MEDIA_STREAM_DIRECTION_SEND = 1
MEDIA_STREAM_DIRECTION_RECEIVE = 2
MEDIA_STREAM_DIRECTION_BIDIRECTIONAL = 3
-CLIENT = tp_name_prefix + '.Client.DRAFT'
+CLIENT = tp_name_prefix + '.Client'
CLIENT_PATH = tp_path_prefix + '/Client'
-OBSERVER = tp_name_prefix + '.Client.Observer.DRAFT'
-APPROVER = tp_name_prefix + '.Client.Approver.DRAFT'
-HANDLER = tp_name_prefix + '.Client.Handler.DRAFT'
-HANDLER_IFACE_REQUEST_NOTIFICATION = tp_name_prefix + '.Client.Handler.Interface.RequestNotification.DRAFT'
+OBSERVER = tp_name_prefix + '.Client.Observer'
+APPROVER = tp_name_prefix + '.Client.Approver'
+HANDLER = tp_name_prefix + '.Client.Handler'
+CLIENT_IFACE_REQUESTS = CLIENT + '.Interface.Requests'
ACCOUNT = tp_name_prefix + '.Account'
ACCOUNT_IFACE_AVATAR = ACCOUNT + '.Interface.Avatar'
@@ -138,9 +138,8 @@ AM_IFACE_NOKIA_QUERY = 'com.nokia.AccountManager.Interface.Query'
AM_PATH = tp_path_prefix + '/AccountManager'
CR = tp_name_prefix + '.ChannelRequest'
-CDO = tp_name_prefix + '.ChannelDispatchOperation.DRAFT'
+CDO = tp_name_prefix + '.ChannelDispatchOperation'
-CD = tp_name_prefix + '.ChannelDispatcher.DRAFT'
-CD_BUS_NAME = tp_name_prefix + '.ChannelDispatcher'
-CD_IFACE_OP_LIST = tp_name_prefix + '.ChannelDispatcher.Interface.OperationList.DRAFT'
+CD = tp_name_prefix + '.ChannelDispatcher'
+CD_IFACE_OP_LIST = tp_name_prefix + '.ChannelDispatcher.Interface.OperationList'
CD_PATH = tp_path_prefix + '/ChannelDispatcher'
diff --git a/test/twisted/dispatcher/already-has-channel.py b/test/twisted/dispatcher/already-has-channel.py
index 5b21827..d991a75 100644
--- a/test/twisted/dispatcher/already-has-channel.py
+++ b/test/twisted/dispatcher/already-has-channel.py
@@ -100,7 +100,7 @@ def test(q, bus, mc):
# subscribe to the OperationList interface (MC assumes that until this
# property has been retrieved once, nobody cares)
- cd = bus.get_object(cs.CD_BUS_NAME, cs.CD_PATH)
+ cd = bus.get_object(cs.CD, cs.CD_PATH)
cd_props = dbus.Interface(cd, cs.PROPERTIES_IFACE)
assert cd_props.Get(cs.CD_IFACE_OP_LIST, 'DispatchOperations') == []
@@ -152,7 +152,7 @@ def test(q, bus, mc):
assert cd_props.Get(cs.CD_IFACE_OP_LIST, 'DispatchOperations') ==\
[(cdo_path, cdo_properties)]
- cdo = bus.get_object(cs.CD_BUS_NAME, cdo_path)
+ cdo = bus.get_object(cs.CD, cdo_path)
cdo_iface = dbus.Interface(cdo, cs.CDO)
# Both Observers are told about the new channel
diff --git a/test/twisted/dispatcher/cancel.py b/test/twisted/dispatcher/cancel.py
index 44c900d..9cc885d 100644
--- a/test/twisted/dispatcher/cancel.py
+++ b/test/twisted/dispatcher/cancel.py
@@ -61,7 +61,7 @@ def test_channel_creation(q, bus, account, client, conn,
user_action_time = dbus.Int64(1238582606)
- cd = bus.get_object(cs.CD_BUS_NAME, cs.CD_PATH)
+ cd = bus.get_object(cs.CD, cs.CD_PATH)
cd_props = dbus.Interface(cd, cs.PROPERTIES_IFACE)
# chat UI calls ChannelDispatcher.CreateChannel
@@ -79,23 +79,20 @@ def test_channel_creation(q, bus, account, client, conn,
request_path = ret.value[0]
cr = bus.get_object(cs.AM, request_path)
- # FIXME: MC gives CR properties to clients without .DRAFT, but the
- # CR itself is really still .DRAFT
- request_props = cr.GetAll(cs.CR + '.DRAFT',
- dbus_interface=cs.PROPERTIES_IFACE)
+ request_props = cr.GetAll(cs.CR, dbus_interface=cs.PROPERTIES_IFACE)
assert request_props['Account'] == account.object_path
assert request_props['Requests'] == [request]
assert request_props['UserActionTime'] == user_action_time
if cancel_before_proceed:
- cr.Cancel(dbus_interface=cs.CR + '.DRAFT')
+ cr.Cancel(dbus_interface=cs.CR)
accsig, stdsig = q.expect_many(
EventPattern('dbus-signal', path=account.object_path,
interface=cs.ACCOUNT_IFACE_NOKIA_REQUESTS,
signal='Failed'),
EventPattern('dbus-signal', path=request_path,
- interface=cs.CR + '.DRAFT', signal='Failed'),
+ interface=cs.CR, signal='Failed'),
)
assert accsig.args[0] == request_path
assert accsig.args[1] == cs.CANCELLED
@@ -103,7 +100,7 @@ def test_channel_creation(q, bus, account, client, conn,
# the channel request has gone away
try:
- cr.Proceed(dbus_interface=cs.CR + '.DRAFT')
+ cr.Proceed(dbus_interface=cs.CR)
except dbus.DBusException, e:
pass
else:
@@ -111,14 +108,14 @@ def test_channel_creation(q, bus, account, client, conn,
return
- cr.Proceed(dbus_interface=cs.CR + '.DRAFT')
+ cr.Proceed(dbus_interface=cs.CR)
cm_request_call, add_request_call = q.expect_many(
EventPattern('dbus-method-call',
interface=cs.CONN_IFACE_REQUESTS, method='CreateChannel',
path=conn.object_path, args=[request], handled=False),
EventPattern('dbus-method-call', handled=False,
- interface=cs.HANDLER_IFACE_REQUEST_NOTIFICATION,
+ interface=cs.CLIENT_IFACE_REQUESTS,
method='AddRequest', path=client.object_path),
)
@@ -126,7 +123,7 @@ def test_channel_creation(q, bus, account, client, conn,
q.dbus_return(add_request_call.message, signature='')
# Actually, never mind.
- cr.Cancel(dbus_interface=cs.CR + '.DRAFT')
+ cr.Cancel(dbus_interface=cs.CR)
# Time passes. A channel is returned.
@@ -150,7 +147,7 @@ def test_channel_creation(q, bus, account, client, conn,
EventPattern('dbus-signal', path=account.object_path,
interface=cs.ACCOUNT_IFACE_NOKIA_REQUESTS, signal='Failed'),
EventPattern('dbus-signal', path=request_path,
- interface=cs.CR + '.DRAFT', signal='Failed'),
+ interface=cs.CR, signal='Failed'),
EventPattern('dbus-method-call', path=channel.object_path,
interface=cs.CHANNEL, method='Close', handled=True),
)
diff --git a/test/twisted/dispatcher/create-text.py b/test/twisted/dispatcher/create-text.py
index 2ea3df8..855dfd5 100644
--- a/test/twisted/dispatcher/create-text.py
+++ b/test/twisted/dispatcher/create-text.py
@@ -59,7 +59,7 @@ def test(q, bus, mc):
def test_channel_creation(q, bus, account, client, conn, ensure):
user_action_time = dbus.Int64(1238582606)
- cd = bus.get_object(cs.CD_BUS_NAME, cs.CD_PATH)
+ cd = bus.get_object(cs.CD, cs.CD_PATH)
cd_props = dbus.Interface(cd, cs.PROPERTIES_IFACE)
# chat UI calls ChannelDispatcher.EnsureChannel or CreateChannel
@@ -81,17 +81,14 @@ def test_channel_creation(q, bus, account, client, conn, ensure):
# chat UI connects to signals and calls ChannelRequest.Proceed()
cr = bus.get_object(cs.AM, request_path)
- # FIXME: MC gives CR properties to clients without .DRAFT, but the
- # CR itself is really still .DRAFT
- request_props = cr.GetAll(cs.CR + '.DRAFT',
- dbus_interface=cs.PROPERTIES_IFACE)
+ request_props = cr.GetAll(cs.CR, dbus_interface=cs.PROPERTIES_IFACE)
assert request_props['Account'] == account.object_path
assert request_props['Requests'] == [request]
assert request_props['UserActionTime'] == user_action_time
assert request_props['PreferredHandler'] == client.bus_name
assert request_props['Interfaces'] == []
- cr.Proceed(dbus_interface=cs.CR + '.DRAFT')
+ cr.Proceed(dbus_interface=cs.CR)
# FIXME: should the EnsureChannel/CreateChannel call, and the AddRequest
# call, be in a defined order? Probably not though, since CMs and Clients
@@ -103,7 +100,7 @@ def test_channel_creation(q, bus, account, client, conn, ensure):
method=(ensure and 'EnsureChannel' or 'CreateChannel'),
path=conn.object_path, args=[request], handled=False),
EventPattern('dbus-method-call', handled=False,
- interface=cs.HANDLER_IFACE_REQUEST_NOTIFICATION,
+ interface=cs.CLIENT_IFACE_REQUESTS,
method='AddRequest', path=client.object_path),
)
@@ -182,7 +179,7 @@ def test_channel_creation(q, bus, account, client, conn, ensure):
interface=cs.ACCOUNT_IFACE_NOKIA_REQUESTS, signal='Succeeded',
args=[request_path]),
EventPattern('dbus-signal', path=request_path,
- interface=cs.CR + '.DRAFT', signal='Succeeded'),
+ interface=cs.CR, signal='Succeeded'),
)
# Close the channel
diff --git a/test/twisted/dispatcher/dispatch-text.py b/test/twisted/dispatcher/dispatch-text.py
index 30413bf..fc580e9 100644
--- a/test/twisted/dispatcher/dispatch-text.py
+++ b/test/twisted/dispatcher/dispatch-text.py
@@ -69,7 +69,7 @@ def test(q, bus, mc):
# subscribe to the OperationList interface (MC assumes that until this
# property has been retrieved once, nobody cares)
- cd = bus.get_object(cs.CD_BUS_NAME, cs.CD_PATH)
+ cd = bus.get_object(cs.CD, cs.CD_PATH)
cd_props = dbus.Interface(cd, cs.PROPERTIES_IFACE)
assert cd_props.Get(cs.CD_IFACE_OP_LIST, 'DispatchOperations') == []
@@ -110,7 +110,7 @@ def test(q, bus, mc):
assert cd_props.Get(cs.CD_IFACE_OP_LIST, 'DispatchOperations') ==\
[(cdo_path, cdo_properties)]
- cdo = bus.get_object(cs.CD_BUS_NAME, cdo_path)
+ cdo = bus.get_object(cs.CD, cdo_path)
cdo_iface = dbus.Interface(cdo, cs.CDO)
# Both Observers are told about the new channel
diff --git a/test/twisted/dispatcher/exploding-bundles.py b/test/twisted/dispatcher/exploding-bundles.py
index b918c08..e6ea956 100644
--- a/test/twisted/dispatcher/exploding-bundles.py
+++ b/test/twisted/dispatcher/exploding-bundles.py
@@ -83,7 +83,7 @@ def test(q, bus, mc):
# subscribe to the OperationList interface (MC assumes that until this
# property has been retrieved once, nobody cares)
- cd = bus.get_object(cs.CD_BUS_NAME, cs.CD_PATH)
+ cd = bus.get_object(cs.CD, cs.CD_PATH)
cd_props = dbus.Interface(cd, cs.PROPERTIES_IFACE)
assert cd_props.Get(cs.CD_IFACE_OP_LIST, 'DispatchOperations') == []
@@ -143,7 +143,7 @@ def test(q, bus, mc):
assert cd_props.Get(cs.CD_IFACE_OP_LIST, 'DispatchOperations') ==\
[(cdo_path, cdo_properties)]
- cdo = bus.get_object(cs.CD_BUS_NAME, cdo_path)
+ cdo = bus.get_object(cs.CD, cdo_path)
cdo_iface = dbus.Interface(cdo, cs.CDO)
# Both Observers are told about the new channels
diff --git a/test/twisted/dispatcher/fdo-21034.py b/test/twisted/dispatcher/fdo-21034.py
index 474ad6a..25fe7ee 100644
--- a/test/twisted/dispatcher/fdo-21034.py
+++ b/test/twisted/dispatcher/fdo-21034.py
@@ -45,7 +45,7 @@ def test(q, bus, mc):
path=client.object_path),
)
- cd = bus.get_object(cs.CD_BUS_NAME, cs.CD_PATH)
+ cd = bus.get_object(cs.CD, cs.CD_PATH)
cd_props = dbus.Interface(cd, cs.PROPERTIES_IFACE)
# chat UI calls ChannelDispatcher.EnsureChannel or CreateChannel
diff --git a/test/twisted/dispatcher/lose-text.py b/test/twisted/dispatcher/lose-text.py
index 642465f..1097311 100644
--- a/test/twisted/dispatcher/lose-text.py
+++ b/test/twisted/dispatcher/lose-text.py
@@ -70,7 +70,7 @@ def test(q, bus, mc):
# subscribe to the OperationList interface (MC assumes that until this
# property has been retrieved once, nobody cares)
- cd = bus.get_object(cs.CD_BUS_NAME, cs.CD_PATH)
+ cd = bus.get_object(cs.CD, cs.CD_PATH)
cd_props = dbus.Interface(cd, cs.PROPERTIES_IFACE)
assert cd_props.Get(cs.CD_IFACE_OP_LIST, 'DispatchOperations') == []
@@ -111,7 +111,7 @@ def test(q, bus, mc):
assert cd_props.Get(cs.CD_IFACE_OP_LIST, 'DispatchOperations') ==\
[(cdo_path, cdo_properties)]
- cdo = bus.get_object(cs.CD_BUS_NAME, cdo_path)
+ cdo = bus.get_object(cs.CD, cdo_path)
cdo_iface = dbus.Interface(cdo, cs.CDO)
# Both Observers are told about the new channel
diff --git a/test/twisted/fakeclient.py b/test/twisted/fakeclient.py
index 93a85a0..805d296 100644
--- a/test/twisted/fakeclient.py
+++ b/test/twisted/fakeclient.py
@@ -3,10 +3,10 @@ import dbus.service
from servicetest import Event
from servicetest import EventPattern, tp_name_prefix, tp_path_prefix
-client_iface = "org.freedesktop.Telepathy.Client.DRAFT"
-client_observer_iface = "org.freedesktop.Telepathy.Client.Observer.DRAFT"
-client_approver_iface = "org.freedesktop.Telepathy.Client.Approver.DRAFT"
-client_handler_iface = "org.freedesktop.Telepathy.Client.Handler.DRAFT"
+client_iface = "org.freedesktop.Telepathy.Client"
+client_observer_iface = "org.freedesktop.Telepathy.Client.Observer"
+client_approver_iface = "org.freedesktop.Telepathy.Client.Approver"
+client_handler_iface = "org.freedesktop.Telepathy.Client.Handler"
properties_iface = "org.freedesktop.DBus.Properties"
diff --git a/test/twisted/mctest.py b/test/twisted/mctest.py
index c61c46d..03239bd 100644
--- a/test/twisted/mctest.py
+++ b/test/twisted/mctest.py
@@ -381,7 +381,7 @@ class SimulatedClient(object):
ret.append(cs.HANDLER)
if self.request_notification:
- ret.append(cs.HANDLER_IFACE_REQUEST_NOTIFICATION)
+ ret.append(cs.CLIENT_IFACE_REQUESTS)
return ret
diff --git a/xml/Channel_Dispatch_Operation.xml b/xml/Channel_Dispatch_Operation.xml
index fdee944..a44712c 100644
--- a/xml/Channel_Dispatch_Operation.xml
+++ b/xml/Channel_Dispatch_Operation.xml
@@ -21,14 +21,14 @@
MA 02110-1301, USA.</p>
</tp:license>
- <interface name="org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT"
- tp:causes-havoc="experimental">
+ <interface name="org.freedesktop.Telepathy.ChannelDispatchOperation"
+ tp:causes-havoc="not yet final">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>A channel dispatch operation is an object in the ChannelDispatcher
- representing a bundle of unrequested channels being announced to
+ representing a batch of unrequested channels being announced to
client
- <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver.DRAFT</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver</tp:dbus-ref>
processes.</p>
<p>These objects can result from new incoming channels or channels
@@ -52,9 +52,9 @@
<p>First, the channel dispatcher SHOULD construct a list of all the
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client">Handler.DRAFT</tp:dbus-ref>s
+ namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>s
that could handle all the channels (based on their <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandlerChannelFilter</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
property), ordered by
priority in some implementation-dependent way. If there are handlers
which could handle all the channels, one channel dispatch operation
@@ -62,15 +62,34 @@
dispatch operation SHOULD be created for each channel, each with
a list of channel handlers that could handle that channel.</p>
+ <p>If no handler at all can handle a channel, the channel dispatcher
+ SHOULD terminate that channel instead of creating a channel dispatcher
+ for it. It is RECOMMENDED that the channel dispatcher closes
+ the channels using <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">Channel.Interface.Destroyable.Destroy</tp:dbus-ref>
+ if supported, or <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">Channel.Close</tp:dbus-ref>
+ otherwise. As a special case, the channel dispatcher SHOULD NOT close
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Channel.Type">ContactList</tp:dbus-ref>
+ channels, and if Close fails, the channel dispatcher SHOULD ignore
+ that channel.</p>
+
+ <tp:rationale>
+ <p>ContactList channels are strange. We hope to replace them with
+ something better, such as an interface on the Connection, in a
+ future version of this specification.</p>
+ </tp:rationale>
+
<p>When listing channel handlers, priority SHOULD be given to
channel handlers that are already handling channels from the same
bundle.</p>
<p>If a handler with <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">BypassApproval</tp:dbus-ref>
- <code>= True</code> could handle the channels in the dispatch
+ namespace="org.freedesktop.Telepathy.Client.Handler">BypassApproval</tp:dbus-ref>
+ <code>= True</code> could handle all of the channels in the dispatch
operation, then the channel dispatcher SHOULD call <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
on that handler, and (assuming the call succeeds) emit
<tp:member-ref>Finished</tp:member-ref> and stop processing those
channels without involving any approvers.</p>
@@ -92,7 +111,7 @@
approver to claim the channels or request that they are handled.
See
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Approver.DRAFT">AddDispatchOperation</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Client.Approver">AddDispatchOperation</tp:dbus-ref>
for more details on this.</p>
<p>Finally, if the approver requested it, the channel dispatcher SHOULD
@@ -142,11 +161,29 @@
</property>
<signal name="ChannelLost" tp:name-for-bindings="Channel_Lost">
- <tp:docstring>
- A channel has closed before it could be claimed or handled. If this
- is emitted for the last remaining channel in a channel dispatch
- operation, it MUST immediately be followed by
- <tp:member-ref>Finished</tp:member-ref>.
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>A channel has closed before it could be claimed or handled. If
+ this is emitted for the last remaining channel in a channel
+ dispatch operation, it MUST immediately be followed by
+ <tp:member-ref>Finished</tp:member-ref>.</p>
+
+ <p>This signal MUST NOT be emitted until all Approvers that were
+ invoked have returned (successfully or with an error) from
+ their <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client.Approver">AddDispatchOperation</tp:dbus-ref>
+ method.</p>
+
+ <tp:rationale>
+ <p>This means that Approvers can connect to the ChannelLost signal
+ in a race-free way. Non-approver processes that discover
+ a channel dispatch operation in some way (such as observers)
+ will have to follow the usual "connect to signals then recover
+ state" model - first connect to ChannelLost and
+ <tp:member-ref>Finished</tp:member-ref>,
+ then download <tp:member-ref>Channels</tp:member-ref> (and
+ on error, perhaps assume that the operation has already
+ Finished).</p>
+ </tp:rationale>
</tp:docstring>
<arg name="Channel" type="o">
@@ -164,17 +201,6 @@
<code>org.freedesktop.Telepathy.Error.NotAvailable</code> MAY
be used as a fallback; this means that this error SHOULD NOT be
given any more specific meaning.</p>
-
- <p>FIXME: or should we invent a new OtherError for that purpose?</p>
-
- <p>FIXME: we need to specify errors for these situations:</p>
-
- <ul>
- <li>kicked from a chatroom</li>
- <li>outgoing call rejected</li>
- <li>outgoing call timed out</li>
- <li>incoming call terminated</li>
- </ul>
</tp:docstring>
</arg>
@@ -188,13 +214,22 @@
<property name="PossibleHandlers" tp:name-for-bindings="Possible_Handlers"
type="as" access="read" tp:type="DBus_Well_Known_Name[]">
<tp:docstring>
- The well known bus names (starting with
- <code>org.freedesktop.Telepathy.Client.</code>) of the possible
- <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client">Handler.DRAFT</tp:dbus-ref>s
- for these channels. The channel dispatcher MUST place the most
- preferred handlers first, according to some reasonable heuristic.
- As a result, approvers SHOULD use the first handler by default.
+ <p>The well known bus names (starting with
+ <code>org.freedesktop.Telepathy.Client.</code>) of the possible
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>s
+ for these channels. The channel dispatcher MUST place the most
+ preferred handlers first, according to some reasonable heuristic.
+ As a result, approvers SHOULD use the first handler by default.</p>
+
+ <p>The heuristic used to prioritize handlers SHOULD give a higher
+ priority to handlers that are already running.</p>
+
+ <tp:rationale>
+ <p>If, for instance, Empathy and Kopete have similar functionality,
+ and Empathy is running, we should prefer to send channels to it
+ rather than launching Kopete via service activation.</p>
+ </tp:rationale>
</tp:docstring>
</property>
@@ -222,7 +257,7 @@
<p>(FIXME: list some possible errors)</p>
<p>If the channel handler raises an error from <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>,
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>,
this method
MAY respond by raising that same error, even if it is not
specifically documented here.</p>
@@ -232,15 +267,16 @@
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The well-known bus name (starting with
<code>org.freedesktop.Telepathy.Client.</code>) of the channel
- handler that should handle the channel.</p>
+ handler that should handle the channel, or the empty string
+ if the client has no preferred channel handler.</p>
</tp:docstring>
</arg>
<tp:possible-errors>
<tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- The selected handler is not a syntactically correct
- <tp:type>DBus_Bus_Name</tp:type> or does not start with
+ The selected handler is non-empty, but is not a syntactically
+ correct <tp:type>DBus_Bus_Name</tp:type> or does not start with
"<code>org.freedesktop.Telepathy.Client.</code>".
</tp:docstring>
</tp:error>
@@ -278,13 +314,15 @@
<p>Called by an approver to claim channels for handling
internally. If this method is called successfully, the process
calling this method becomes the handler for the channel, but
- <em>does not</em> have the HandleChannels method called on it.</p>
- <!-- FIXME: tp:dbus-ref -->
+ <em>does not</em> have the <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
+ method called on it.</p>
<p>Clients that call Claim on channels but do not immediately
close them SHOULD implement the Handler interface and its
- CurrentlyHandledChannels property.</p>
- <!-- FIXME: tp:dbus-ref -->
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandledChannels</tp:dbus-ref>
+ property.</p>
<p>Approvers wishing to reject channels MUST call this method to
claim ownership of them, and MUST NOT call
@@ -297,7 +335,14 @@
For instance, for Text channels it is necessary
to acknowledge any messages that have already been displayed to
the user first - ideally, the approver would display and then
- acknowledge the messages.</p>
+ acknowledge the messages - or to call <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">Channel.Interface.Destroyable.Destroy</tp:dbus-ref>
+ if the destructive behaviour of that method is desired.</p>
+
+ <p>Similarly, an Approver for StreamedMedia channels can close the
+ channel with a reason (e.g. "busy") if desired. The channel
+ dispatcher, which is designed to have no specific knowledge
+ of particular channel types, can't do that.</p>
</tp:rationale>
<p>If successful, this method will cause the ChannelDispatchOperation
@@ -331,6 +376,11 @@
operation is no longer present and further methods must not be
called on it.</p>
+ <p>Approvers that have a user interface SHOULD stop notifying the user
+ about the channels in response to this signal; they MAY assume that
+ on errors, they would have received
+ <tp:member-ref>ChannelLost</tp:member-ref> first.</p>
+
<p>Its object path SHOULD NOT be reused for a subsequent dispatch
operation; the ChannelDispatcher MUST choose object paths
in a way that avoids immediate re-use.</p>
@@ -341,6 +391,24 @@
<tp:member-ref>Claim</tp:member-ref> on a new dispatch operation
instead of the one they intended to handle.</p>
</tp:rationale>
+
+ <p>This signal MUST NOT be emitted until all Approvers that were
+ invoked have returned (successfully or with an error) from
+ their <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client.Approver">AddDispatchOperation</tp:dbus-ref>
+ method.</p>
+
+ <tp:rationale>
+ <p>This means that Approvers can connect to the ChannelLost signal
+ in a race-free way. Non-approver processes that discover
+ a channel dispatch operation in some way (such as observers)
+ will have to follow the usual "connect to signals then recover
+ state" model - first connect to
+ <tp:member-ref>ChannelLost</tp:member-ref> and
+ Finished, then download <tp:member-ref>Channels</tp:member-ref>
+ (and on error, perhaps assume that the operation has already
+ Finished).</p>
+ </tp:rationale>
</tp:docstring>
</signal>
diff --git a/xml/Channel_Dispatcher.xml b/xml/Channel_Dispatcher.xml
index af671bd..8680f6d 100644
--- a/xml/Channel_Dispatcher.xml
+++ b/xml/Channel_Dispatcher.xml
@@ -21,8 +21,8 @@
USA.</p>
</tp:license>
- <interface name="org.freedesktop.Telepathy.ChannelDispatcher.DRAFT"
- tp:causes-havoc="experimental">
+ <interface name="org.freedesktop.Telepathy.ChannelDispatcher"
+ tp:causes-havoc="not yet final">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The channel dispatcher is responsible for responding to new
@@ -67,12 +67,14 @@
specification:</p>
<dl>
- <dt>Observer</dt>
+ <dt><tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client">Observer</tp:dbus-ref></dt>
<dd><p>Observers monitor the creation of new channels. This
functionality can be used for things like message logging.
All observers are notified simultaneously.</p></dd>
- <dt>Approver</dt>
+ <dt><tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client">Approver</tp:dbus-ref></dt>p
<dd>
<p>Approvers notify the user that new channels have been created,
and also select which channel handler will be used for the channel,
@@ -80,7 +82,8 @@
channel handler.</p>
</dd>
- <dt>Handler</dt>
+ <dt><tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref></dt>
<dd>
<p>Each new channel or set of channels is passed to exactly one
handler as its final destination. A typical channel handler is a
@@ -99,7 +102,7 @@
<method name="CreateChannel" tp:name-for-bindings="Create_Channel">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Start a request to create a channel. This initially just creates a
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
object, which can be used to continue the request and track its
success or failure.</p>
@@ -119,10 +122,10 @@
<p>If this method is called for an Account that is disabled, invalid
or otherwise unusable, no error is signalled until
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT.Proceed</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy">ChannelRequest.Proceed</tp:dbus-ref>
is called, at which point
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT.Failed</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy">ChannelRequest.Failed</tp:dbus-ref>
is emitted with an appropriate error.</p>
<tp:rationale>
@@ -166,10 +169,10 @@
<p>The time at which user action occurred, or 0 if this channel
request is for some reason not involving user action.
The <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelRequest.DRAFT">UserActionTime</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelRequest">UserActionTime</tp:dbus-ref>
property will be set to this value, and it will eventually be
passed as the <code>User_Action_Time</code> parameter of <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>.</p>
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>.</p>
</tp:docstring>
</arg>
@@ -193,14 +196,15 @@
<p>This is partly so the channel dispatcher can call
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
on it, and partly so the channel dispatcher
can recover state if it crashes and is restarted.</p>
</tp:rationale>
- <p>If this is a well-known bus name, the channel dispatcher SHOULD
+ <p>If this is a well-known bus name and the handler has the
+ Requests interface, the channel dispatcher SHOULD
call <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">AddRequest</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Client.Interface.Requests">AddRequest</tp:dbus-ref>
on that Handler after this method has returned.</p>
<tp:rationale>
@@ -208,13 +212,18 @@
itself as the preferred handler to associate the call to
AddRequest with that call.</p>
</tp:rationale>
+
+ <p>This is copied to the ChannelRequest that is returned,
+ as the <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.ChannelRequest">PreferredHandler</tp:dbus-ref>
+ property.</p>
</tp:docstring>
</arg>
<arg direction="out" name="Request" type="o">
<tp:docstring>
A
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
object.
</tp:docstring>
</arg>
@@ -236,22 +245,22 @@
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Start a request to ensure that a channel exists, creating it if
necessary. This initially just creates a <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
object, which can be used to continue the request and track its
success or failure.</p>
<p>If this method is called for an Account that is disabled, invalid
or otherwise unusable, no error is signalled until
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT.Proceed</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy">ChannelRequest.Proceed</tp:dbus-ref>
is called, at which point
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT.Failed</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy">ChannelRequest.Failed</tp:dbus-ref>
is emitted with an appropriate error.</p>
<tp:rationale>
<p>The rationale is as for <tp:dbus-ref
- namespace='org.freedesktop.Telepathy.ChannelDispatcher.DRAFT'>CreateChannel</tp:dbus-ref>.</p>
+ namespace='org.freedesktop.Telepathy.ChannelDispatcher'>CreateChannel</tp:dbus-ref>.</p>
</tp:rationale>
</tp:docstring>
@@ -284,12 +293,10 @@
tp:type="Unix_Timestamp64">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The time at which user action occurred, or 0 if this channel
- request is for some reason not involving user action.
- The <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelRequest.DRAFT">UserActionTime</tp:dbus-ref>
- property will be set to this value, and it will eventually be
- passed as the <code>User_Action_Time</code> parameter of <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>.</p>
+ request is for some reason not involving user action.</p>
+
+ <p>This parameter is used in the same way as the corresponding
+ parameter to <tp:member-ref>CreateChannel</tp:member-ref>.</p>
</tp:docstring>
</arg>
@@ -300,30 +307,10 @@
<code>org.freedesktop.Telepathy.Client.</code>)
of the preferred handler for this
channel, or an empty string to indicate that any handler would be
- acceptable.</p>
-
- <tp:rationale>
- <p>This must be the well-known bus name, not the unique name,
- to ensure that all handlers do indeed have the Client API,
- and the Client object on the handler can be located easily.</p>
-
- <p>This is partly so the channel dispatcher can call
- <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>
- on it, and partly so the channel dispatcher
- can recover state if it crashes and is restarted.</p>
- </tp:rationale>
-
- <p>If this is a well-known bus name, the channel dispatcher SHOULD
- call <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">AddRequest</tp:dbus-ref>
- on that Handler after this method has returned.</p>
-
- <tp:rationale>
- <p>This ordering allows a Handler which calls EnsureChannel with
- itself as the preferred handler to associate the call to
- AddRequest with that call.</p>
- </tp:rationale>
+ acceptable. The behaviour and rationale are the same as for the
+ corresponding parameter to
+ <tp:member-ref>CreateChannel</tp:member-ref>, except as noted
+ here.</p>
<p>If any new channels are created in response to this
request, the channel dispatcher SHOULD dispatch as many as
@@ -340,11 +327,11 @@
<tp:rationale>
<p>An address book application, for example, might call <tp:dbus-ref
- namespace='org.freedesktop.Telepathy.ChannelDispatcher.DRAFT'>EnsureChannel</tp:dbus-ref>
+ namespace='org.freedesktop.Telepathy.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>
to ensure that a text channel with a particular contact is
displayed to the user; it does not care whether a new channel was
made. An IM client might call <tp:dbus-ref
- namespace='org.freedesktop.Telepathy.ChannelDispatcher.DRAFT'>EnsureChannel</tp:dbus-ref>
+ namespace='org.freedesktop.Telepathy.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>
in response to the user double-clicking an entry in the contact
list, with itself as the <code>Preferred_Handler</code>; if the
user already has a conversation with that contact in another
@@ -360,7 +347,7 @@
<arg direction="out" name="Request" type="o">
<tp:docstring>
A
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
object.
</tp:docstring>
</arg>
diff --git a/xml/Channel_Dispatcher_Interface_Operation_List.xml b/xml/Channel_Dispatcher_Interface_Operation_List.xml
index 7a1c0e1..e3270ce 100644
--- a/xml/Channel_Dispatcher_Interface_Operation_List.xml
+++ b/xml/Channel_Dispatcher_Interface_Operation_List.xml
@@ -21,10 +21,10 @@
USA.</p>
</tp:license>
- <interface name="org.freedesktop.Telepathy.ChannelDispatcher.Interface.OperationList.DRAFT"
- tp:causes-havoc="experimental">
+ <interface name="org.freedesktop.Telepathy.ChannelDispatcher.Interface.OperationList"
+ tp:causes-havoc="not yet final">
- <tp:requires interface="org.freedesktop.Telepathy.ChannelDispatcher.DRAFT"/>
+ <tp:requires interface="org.freedesktop.Telepathy.ChannelDispatcher"/>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>This interface allows users of the ChannelDispatcher to enumerate
@@ -51,7 +51,7 @@
<tp:docstring>
The object path of the
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT</tp:dbus-ref>.
+ namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>.
</tp:docstring>
</tp:member>
@@ -71,11 +71,10 @@
<p>Each dictionary MUST contain at least the following keys:</p>
<ul>
- <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT.Interfaces</tp:dbus-ref></li>
- <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT.Connection</tp:dbus-ref></li>
- <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT.Account</tp:dbus-ref></li>
- <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT.Channels</tp:dbus-ref></li>
- <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT.PossibleHandlers</tp:dbus-ref></li>
+ <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.Interfaces</tp:dbus-ref></li>
+ <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.Connection</tp:dbus-ref></li>
+ <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.Account</tp:dbus-ref></li>
+ <li><tp:dbus-ref>org.freedesktop.Telepathy.ChannelDispatchOperation.PossibleHandlers</tp:dbus-ref></li>
</ul>
</tp:docstring>
</tp:member>
@@ -119,7 +118,7 @@
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
Emitted when a dispatch operation finishes (i.e. exactly once per
emission of <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT.Finished</tp:dbus-ref>).
+ namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.Finished</tp:dbus-ref>).
<tp:rationale>
Strictly speaking this is redundant with
diff --git a/xml/Channel_Request.xml b/xml/Channel_Request.xml
index 32eca34..c69266a 100644
--- a/xml/Channel_Request.xml
+++ b/xml/Channel_Request.xml
@@ -21,8 +21,8 @@
MA 02110-1301, USA.</p>
</tp:license>
- <interface name="org.freedesktop.Telepathy.ChannelRequest.DRAFT"
- tp:causes-havoc="experimental">
+ <interface name="org.freedesktop.Telepathy.ChannelRequest"
+ tp:causes-havoc="not yet final">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>A channel request is an object in the ChannelDispatcher representing
@@ -34,7 +34,7 @@
<tp:rationale>
<p>See
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatcher.DRAFT.CreateChannel</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatcher.CreateChannel</tp:dbus-ref>
for rationale for ChannelRequest being a separate object.</p>
</tp:rationale>
diff --git a/xml/Client.xml b/xml/Client.xml
index 5307efa..ba29900 100644
--- a/xml/Client.xml
+++ b/xml/Client.xml
@@ -20,8 +20,8 @@
02110-1301, USA.</p>
</tp:license>
- <interface name="org.freedesktop.Telepathy.Client.DRAFT"
- tp:causes-havoc="experimental">
+ <interface name="org.freedesktop.Telepathy.Client"
+ tp:causes-havoc="not yet final">
<tp:added version="0.17.12">(as a draft)</tp:added>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
@@ -105,9 +105,9 @@
<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.DRAFT</tp:dbus-ref>,
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Approver.DRAFT</tp:dbus-ref> or
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Handler.DRAFT</tp:dbus-ref>.</p>
+ <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.
diff --git a/xml/Client_Approver.xml b/xml/Client_Approver.xml
index 5c8cb21..62f6694 100644
--- a/xml/Client_Approver.xml
+++ b/xml/Client_Approver.xml
@@ -20,17 +20,17 @@
02110-1301, USA.</p>
</tp:license>
- <interface name="org.freedesktop.Telepathy.Client.Approver.DRAFT"
- tp:causes-havoc="experimental">
+ <interface name="org.freedesktop.Telepathy.Client.Approver"
+ tp:causes-havoc="not yet final">
<tp:added version="0.17.12">(as a draft)</tp:added>
- <tp:requires interface="org.freedesktop.Telepathy.Client.DRAFT"/>
+ <tp:requires interface="org.freedesktop.Telepathy.Client"/>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Approvers are clients that notify the user that new channels have
been created by a contact, and allow the user to accept or reject
those channels. The new channels are represented by a <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelDispatcher.DRAFT</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>
object, which is passed to the
<tp:member-ref>AddDispatchOperation</tp:member-ref> method.</p>
@@ -60,9 +60,9 @@
<p>Any approver can approve the handling of a channel dispatch operation
with a particular channel handler by calling the <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT">HandleWith</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">HandleWith</tp:dbus-ref>
method. Approvers can also attempt to <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT">Claim</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">Claim</tp:dbus-ref>
channels; if this succeeds, the approver may handle the channels
itself (if it is also a Handler), or close the channels in order to
reject them.</p>
@@ -86,15 +86,12 @@
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>A specification of the channels in which this approver is
interested. The <tp:member-ref>AddDispatchOperation</tp:member-ref>
- method should be called by the channel dispatcher whenever the
- channels in a channel dispatch operation
- match this description.</p>
-
- <p>(FIXME: what happens if some but not all of the channels
- match this?)</p>
+ method should be called by the channel dispatcher whenever at least
+ one of the channels in a channel dispatch operation matches this
+ description.</p>
<p>This property works in exactly the same way as the
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer.DRAFT.ObserverChannelFilter</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer.ObserverChannelFilter</tp:dbus-ref>
property. In particular, it cannot change while the approver process
continues to own the corresponding Client bus name.</p>
@@ -134,7 +131,7 @@
type="a(oa{sv})" tp:type="Channel_Details[]">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The initial value of the <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT.Channels</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.Channels</tp:dbus-ref>
property, containing the <tp:dbus-ref
namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>s
to be dispatched and their properties.</p>
@@ -145,13 +142,24 @@
property.</p>
</tp:rationale>
+ <p>This argument always contains all of the channels in the channel
+ dispatch operation, even if not all of them actually match
+ the <tp:member-ref>ApproverChannelFilter</tp:member-ref>.</p>
+
+ <tp:rationale>
+ <p>This seems the least bad way to handle such a situation;
+ see the discussion on
+ <a href="http://bugs.freedesktop.org/show_bug.cgi?id=21090">bug
+ #21090</a>.</p>
+ </tp:rationale>
+
<p>The actual channels to be dispatched may reduce as channels are
closed: this is signalled by <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT.ChannelLost</tp:dbus-ref>.
+ namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.ChannelLost</tp:dbus-ref>.
</p>
<p>Approvers SHOULD connect to ChannelLost and <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT.Finished</tp:dbus-ref>.
+ namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.Finished</tp:dbus-ref>.
(if desired) before returning from AddDispatchOperation, since
those signals are guaranteed not to be emitted until after all
AddDispatchOperation calls have returned (with success or failure)
@@ -162,7 +170,7 @@
<arg name="DispatchOperation" type="o" direction="in">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>
to be processed.</p>
</tp:docstring>
</arg>
@@ -174,11 +182,11 @@
include properties that could change, SHOULD include as many
properties as possible given that constraint, and MUST include at
least the <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT">Account</tp:dbus-ref>,
+ namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">Account</tp:dbus-ref>,
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT">Connection</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">Connection</tp:dbus-ref>
and <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT">PossibleHandlers</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">PossibleHandlers</tp:dbus-ref>
properties.</p>
</tp:docstring>
</arg>
diff --git a/xml/Client_Handler.xml b/xml/Client_Handler.xml
index ea38589..da48701 100644
--- a/xml/Client_Handler.xml
+++ b/xml/Client_Handler.xml
@@ -20,11 +20,11 @@
02110-1301, USA.</p>
</tp:license>
- <interface name="org.freedesktop.Telepathy.Client.Handler.DRAFT"
- tp:causes-havoc="experimental">
+ <interface name="org.freedesktop.Telepathy.Client.Handler"
+ tp:causes-havoc="not yet final">
<tp:added version="0.17.12">(as a draft)</tp:added>
- <tp:requires interface="org.freedesktop.Telepathy.Client.DRAFT"/>
+ <tp:requires interface="org.freedesktop.Telepathy.Client"/>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Handlers are the user interface for a channel. They turn an abstract
@@ -49,7 +49,7 @@
<p>When a new incoming channel (one with
<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
= FALSE) is offered to
- <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver.DRAFT</tp:dbus-ref>s
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver</tp:dbus-ref>s
by the channel dispatcher, it also offers the Approvers a list of all
the running or activatable handlers whose
<tp:member-ref>HandlerChannelFilter</tp:member-ref> property
@@ -75,7 +75,7 @@
or for suitable channels that must be handled separately.</p>
<p>This property works in exactly the same way as the
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer.DRAFT.ObserverChannelFilter</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer.ObserverChannelFilter</tp:dbus-ref>
property. In particular, it cannot change while the handler process
continues to own the corresponding Client bus name.</p>
@@ -183,9 +183,9 @@
<p>The requests satisfied by these channels.</p>
<tp:rationale>
- <p>If the handler implements RequestNotification, this tells it
+ <p>If the handler implements Requests, this tells it
that these channels match previous <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.Interface.RequestNotification.DRAFT">AddRequest</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Client.Interface.Requests">AddRequest</tp:dbus-ref>
calls that it may have received.</p>
<p>There can be more than one, if they were EnsureChannel
diff --git a/xml/Client_Handler_Interface_Request_Notification.xml b/xml/Client_Interface_Requests.xml
similarity index 90%
rename from xml/Client_Handler_Interface_Request_Notification.xml
rename to xml/Client_Interface_Requests.xml
index 4e9d7ed..1b0de98 100644
--- a/xml/Client_Handler_Interface_Request_Notification.xml
+++ b/xml/Client_Interface_Requests.xml
@@ -1,5 +1,5 @@
<?xml version="1.0" ?>
-<node name="/Client_Handler_Interface_Request_Notification"
+<node name="/Client_Interface_Requests"
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>
@@ -20,13 +20,13 @@
02110-1301, USA.</p>
</tp:license>
- <interface name="org.freedesktop.Telepathy.Client.Handler.Interface.RequestNotification.DRAFT"
- tp:causes-havoc="experimental">
- <tp:added version="0.17.UNRELEASED">(as a draft; functionality
+ <interface name="org.freedesktop.Telepathy.Client.Interface.Requests"
+ tp:causes-havoc="not yet final">
+ <tp:added version="0.17.23">(as a draft; functionality
moved from Handler)</tp:added>
- <tp:requires interface="org.freedesktop.Telepathy.Client.DRAFT"/>
- <tp:requires interface="org.freedesktop.Telepathy.Client.Handler.DRAFT"/>
+ <tp:requires interface="org.freedesktop.Telepathy.Client"/>
+ <tp:requires interface="org.freedesktop.Telepathy.Client.Handler"/>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>This interface can be implemented by a Handler to be notified about
@@ -49,14 +49,14 @@
a channel request which handler will handle particular channels.
A reasonable heuristic would be to match the request against the
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandlerChannelFilter</tp:dbus-ref>,
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>,
and respect the preferred handler (if any).</p>
</tp:rationale>
<p>If the request succeeds and is given to the expected Handler,
the Requests_Satisfied parameter to
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
can be used to match the channel to a previous AddRequest call.</p>
<tp:rationale>
@@ -76,7 +76,7 @@
and if the channel request succeeds, it SHOULD dispatch the channels
to the expected handler, unless the channels do not match that
handler's <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandlerChannelFilter</tp:dbus-ref>.
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>.
If the channels are not dispatched to the expected handler, the
handler that was expected is notified by the channel dispatcher
calling its <tp:member-ref>RemoveRequest</tp:member-ref> method
@@ -99,11 +99,11 @@
<arg name="Request" type="o" direction="in">
<tp:docstring>
The <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref>
object, which MUST have been returned by <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelDispatcher.DRAFT">CreateChannel</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelDispatcher">CreateChannel</tp:dbus-ref>
or <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelDispatcher.DRAFT">EnsureChannel</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelDispatcher">EnsureChannel</tp:dbus-ref>
before this method is called.
<tp:rationale>
@@ -121,9 +121,9 @@
properties as possible, given that constraint.</p>
<p>In particular, the properties <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelRequest.DRAFT">Requests</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelRequest">Requests</tp:dbus-ref>
and <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelRequest.DRAFT">UserActionTime</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelRequest">UserActionTime</tp:dbus-ref>
MUST be included.</p>
</tp:docstring>
</arg>
diff --git a/xml/Client_Observer.xml b/xml/Client_Observer.xml
index 0d1d5a1..58b67b3 100644
--- a/xml/Client_Observer.xml
+++ b/xml/Client_Observer.xml
@@ -20,11 +20,11 @@
02110-1301, USA.</p>
</tp:license>
- <interface name="org.freedesktop.Telepathy.Client.Observer.DRAFT"
- tp:causes-havoc="experimental">
+ <interface name="org.freedesktop.Telepathy.Client.Observer"
+ tp:causes-havoc="not yet final">
<tp:added version="0.17.12">(as a draft)</tp:added>
- <tp:requires interface="org.freedesktop.Telepathy.Client.DRAFT"/>
+ <tp:requires interface="org.freedesktop.Telepathy.Client"/>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Observers monitor the creation of new channels. This
@@ -56,7 +56,7 @@
channels, doing the actual data transfer for file transfers,
setting up the out-of-band connection for Tubes). The
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client">Handler.DRAFT</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
is responsible for such tasks.</p>
<p>Handlers MAY, of course, delegate responsibility for these
@@ -163,15 +163,15 @@
a local client:</p>
<pre>
-[org.freedesktop.Telepathy.Client.DRAFT]
-Interfaces=org.freedesktop.Telepathy.Client.Observer.DRAFT;
+[org.freedesktop.Telepathy.Client]
+Interfaces=org.freedesktop.Telepathy.Client.Observer;
-[org.freedesktop.Telepathy.Client.Observer.DRAFT.ObserverChannelFilter 0]
+[org.freedesktop.Telepathy.Client.Observer.ObserverChannelFilter 0]
org.freedesktop.Telepathy.Channel.Type s=org.freedesktop.Telepathy.Channel.Type.Text
org.freedesktop.Telepathy.Channel.TargetHandleType u=1
org.freedesktop.Telepathy.Channel.Requested b=true
-[org.freedesktop.Telepathy.Client.Observer.DRAFT.ObserverChannelFilter 1]
+[org.freedesktop.Telepathy.Client.Observer.ObserverChannelFilter 1]
org.freedesktop.Telepathy.Channel.Type s=org.freedesktop.Telepathy.Channel.Type.Text
org.freedesktop.Telepathy.Channel.TargetHandleType u=2
org.freedesktop.Telepathy.Channel.Requested b=true
@@ -205,7 +205,7 @@ org.freedesktop.Telepathy.Channel.Requested b=true
to avoid the following race: text channel logger (observer) gets
ObserveChannels, text channel handler gets
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Client.Handler">HandleChannels</tp:dbus-ref>
channel handler starts up faster and acknowledges messages,
logger never sees those messages.</p>
</tp:rationale>
@@ -256,25 +256,25 @@ org.freedesktop.Telepathy.Channel.Requested b=true
<arg name="Dispatch_Operation" type="o" direction="in">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The path to the <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelDispatchOperation.DRAFT</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy">ChannelDispatchOperation</tp:dbus-ref>
for these channels, or the special value '/' if there is no
ChannelDispatchOperation (because the channels were requested, not
incoming).</p>
<p>If the Observer calls <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT">Claim</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">Claim</tp:dbus-ref>
or <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT">HandleWith</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">HandleWith</tp:dbus-ref>
on the dispatch operation, it MUST be careful to avoid deadlock,
since these methods cannot return until the Observer has returned
from <tp:member-ref>ObserveChannels</tp:member-ref>.</p>
<tp:rationale>
<p>This allows an Observer to <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT">Claim</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.ChannelDispatchOperation">Claim</tp:dbus-ref>
a set of channels without having to match up calls to this method
with calls to <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Approver.DRAFT">AddDispatchOperation</tp:dbus-ref>.</p>
+ namespace="org.freedesktop.Telepathy.Client.Approver">AddDispatchOperation</tp:dbus-ref>.</p>
</tp:rationale>
</tp:docstring>
</arg>
@@ -287,7 +287,7 @@ org.freedesktop.Telepathy.Channel.Requested b=true
If the same process is an Observer and a Handler, it can be useful
to be given this information as soon as possible (it will also
be passed to <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client">Handler.DRAFT.HandleChannels</tp:dbus-ref>).
+ namespace="org.freedesktop.Telepathy.Client">Handler.HandleChannels</tp:dbus-ref>).
</tp:rationale>
</tp:docstring>
</arg>
diff --git a/xml/Makefile.am b/xml/Makefile.am
index 3a73015..ef83840 100644
--- a/xml/Makefile.am
+++ b/xml/Makefile.am
@@ -21,7 +21,7 @@ SPECS = \
Client.xml \
Client_Approver.xml \
Client_Handler.xml \
- Client_Handler_Interface_Request_Notification.xml \
+ Client_Interface_Requests.xml \
Client_Observer.xml \
Connection_Interface_Contact_Capabilities.xml
diff --git a/xml/nmc5.xml b/xml/nmc5.xml
index 50a8926..3c09ca7 100644
--- a/xml/nmc5.xml
+++ b/xml/nmc5.xml
@@ -17,7 +17,7 @@
<xi:include href="Client.xml"/>
<xi:include href="Client_Approver.xml"/>
<xi:include href="Client_Handler.xml"/>
-<xi:include href="Client_Handler_Interface_Request_Notification.xml"/>
+<xi:include href="Client_Interface_Requests.xml"/>
<xi:include href="Client_Observer.xml"/>
<xi:include href="Channel_Dispatcher.xml"/>
--
1.5.6.5
More information about the telepathy-commits
mailing list