From 224a21a88387343c4c7047ced55614594d105785 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Fri, 26 Sep 2008 17:43:42 +0100 Subject: Update spec to 0.17.12 (no code changes) and prepare 0.7.16 release --- NEWS | 28 +- configure.ac | 8 +- spec/Channel_Dispatch_Operation.xml | 331 +++++++++++++++++++++ spec/Channel_Dispatcher.xml | 222 ++++++++++++++ ...Channel_Dispatcher_Interface_Operation_List.xml | 138 +++++++++ spec/Channel_Interface_Call_State.xml | 8 + spec/Channel_Interface_Destroyable.xml | 79 +++++ spec/Channel_Request.xml | 178 +++++++++++ spec/Client.xml | 123 ++++++++ spec/Client_Approver.xml | 135 +++++++++ spec/Client_Handler.xml | 268 +++++++++++++++++ spec/Client_Observer.xml | 230 ++++++++++++++ spec/Makefile.am | 9 + spec/all.xml | 34 ++- spec/errors.xml | 21 +- spec/generic-types.xml | 3 +- telepathy-glib/Makefile.am | 3 +- telepathy-glib/channel-manager.c | 6 +- telepathy-glib/connection.c | 2 +- telepathy-glib/versions/0.7.16.abi | 9 + 20 files changed, 1810 insertions(+), 25 deletions(-) create mode 100644 spec/Channel_Dispatch_Operation.xml create mode 100644 spec/Channel_Dispatcher.xml create mode 100644 spec/Channel_Dispatcher_Interface_Operation_List.xml create mode 100644 spec/Channel_Interface_Destroyable.xml create mode 100644 spec/Channel_Request.xml create mode 100644 spec/Client.xml create mode 100644 spec/Client_Approver.xml create mode 100644 spec/Client_Handler.xml create mode 100644 spec/Client_Observer.xml create mode 100644 telepathy-glib/versions/0.7.16.abi diff --git a/NEWS b/NEWS index 41494b7b9..9bd49e680 100644 --- a/NEWS +++ b/NEWS @@ -1,15 +1,37 @@ -telepathy-glib 0.7.16 (UNRELEASED) +telepathy-glib 0.7.16 (2008-09-26) ================================== +The "could you say that again? I was looking at that bee" release. + Dependencies: -Deprecations: +* To use --enable-gtk-doc you must now have at least gtkdoc 1.10 Enhancements: +* Updated to spec 0.17.12, mainly featuring EnsureChannel + +* We now support EnsureChannel on the Requests interface - to implement this, + put a suitable function pointer in TpChannelManagerIface::ensure_channel + +* Channel factories' RequestChannel implementations no longer need to + validate handles - TpBaseConnection now does this automatically + +* Added a function to compare presence types in order of "availability" + Fixes: -Release notes for projects using code generation: +* The gtkdoc now documents GInterfaces' signals and properties (fd.o #16995, + fd.o #17308) + +* TpBaseConnection::self_handle is unreffed and cleared slightly later, + for the benefit of channel managers that want to use it in their + status-changed(Disconnected) callback + +* Fixed a compiler warning on platforms with daemon(3) in their libc + +* TpChannelManager can no longer be crashed by asking for unsupported + handle types telepathy-glib 0.7.15 (2008-09-18) ================================== diff --git a/configure.ac b/configure.ac index 05a511200..7fc5e8a16 100644 --- a/configure.ac +++ b/configure.ac @@ -11,8 +11,8 @@ AC_PREREQ([2.59]) m4_define([tp_glib_major_version], [0]) m4_define([tp_glib_minor_version], [7]) -m4_define([tp_glib_micro_version], [15]) -m4_define([tp_glib_nano_version], [1]) +m4_define([tp_glib_micro_version], [16]) +m4_define([tp_glib_nano_version], [0]) # If library source has changed since last release, increment revision # If interfaces have been added, removed or changed since last release, @@ -26,9 +26,9 @@ m4_define([tp_glib_nano_version], [1]) # (we don't guarantee that we won't add ABI then remove it again, if it was # never seen in a release). -m4_define([tp_glib_lt_current], [16]) +m4_define([tp_glib_lt_current], [17]) m4_define([tp_glib_lt_revision], [0]) -m4_define([tp_glib_lt_age], [16]) +m4_define([tp_glib_lt_age], [17]) # Some magic m4_define([tp_glib_base_version], diff --git a/spec/Channel_Dispatch_Operation.xml b/spec/Channel_Dispatch_Operation.xml new file mode 100644 index 000000000..dfd4ec3e2 --- /dev/null +++ b/spec/Channel_Dispatch_Operation.xml @@ -0,0 +1,331 @@ + + + + Copyright (C) 2008 Collabora Ltd. + Copyright (C) 2008 Nokia Corporation + +

This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version.

+ +

This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details.

+ +

You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + MA 02110-1301, USA.

+ + + + + +

A channel dispatch operation is an object in the ChannelDispatcher + representing a bundle of unrequested channels being announced to + client + Approver.DRAFT + processes.

+ +

These objects can result from new incoming channels or channels + which are automatically created for some reason, but cannot result + from outgoing requests for channels.

+ +

More specifically, whenever the + Connection.Interface.Requests.NewChannels + signal contains channels whose + Channel.FUTURE.Requested + property is false, or whenever the + Connection.NewChannel + signal contains a channel with suppress_handler false, + one or more ChannelDispatchOperation objects are created for those + channels.

+ +

(If some channels in a NewChannels signal are in different bundles, + this is an error. The channel dispatcher SHOULD recover by treating + the NewChannels signal as if it had been several NewChannels signals + each containing one channel.)

+ +

First, the channel dispatcher SHOULD construct a list of all the + channel handlers that could handle all the channels, ordered by + priority in some implementation-dependent way. If there are handlers + which could handle all the channels, one channel dispatch operation + SHOULD be created for all the channels. If there are not, one channel + dispatch operation SHOULD be created for each channel, each with + a list of channel handlers that could handle that channel.

+ +

When listing channel handlers, priority SHOULD be given to + channel handlers that are already handling channels from the same + bundle.

+ +

Processing of a channel dispatch operation proceeds as follows. + If the channels in a channel dispatch operation are in the same + bundle as a channel that is already being handled, and the handler + could also handle the channels being dispatched, the channel + dispatcher SHOULD call the handler's + HandleAdditionalChannels + method to see whether the handler will accept the new channels too. + If the handler takes responsibility for the channels, + processing stops, and no approvers are run.

+ +

(FIXME: this is far too subtle and everyone will get it wrong. + Open issue: how else do we address this use case?)

+ + +

Some channel types can be picked up "quietly" by an existing + channel handler. If a Text channel is added to an existing + bundle containing a StreamedMedia channel, there shouldn't be + any approvers, flashing icons or notification bubbles, if the + the UI for the StreamedMedia channel can just add a text box + and display the message.

+ + +

If not, the channel dispatcher SHOULD send the channel dispatch + operation to all relevant approvers (in parallel) and wait for an + approver to claim the channels or request that they are handled. + See + AddDispatchOperation + for more details on this.

+ +

Finally, if the approver requested it, the channel dispatcher SHOULD + send the channels to a handler.

+ + + + + A list of the extra interfaces provided by this channel dispatch + operation. This property cannot change. + + + + + + The Connection + with which the Channels are + associated. The well-known bus name to use can be derived from + this object path by removing the leading '/' and replacing all + subsequent '/' by '.'. This property cannot change. + + + + + + The Account + with which the Connection + and Channels are + associated. This property cannot change. + + + + + + The Channels + to be dispatched, and their properties. Change notification is via + the ChannelLost signal (channels + cannot be added to this property, only removed). + + + + + + A channel has closed before it could be claimed or handled. + + + + +

The name of a D-Bus error indicating why the channel closed. If + no better reason can be found, + org.freedesktop.Telepathy.Errors.NotAvailable MAY + be used as a fallback; this means that this error SHOULD NOT be + given any more specific meaning.

+ +

FIXME: or should we invent a new OtherError for that purpose?

+ +

FIXME: we need to specify errors for these situations:

+ +
    +
  • kicked from a chatroom
    • +
  • outgoing call rejected
    • +
  • outgoing call timed out
    • +
  • incoming call terminated
    • +
+ + + + + + A string associated with the D-Bus error. + + + + + + + The well known bus names (starting with + org.freedesktop.Telepathy.Client.) of the possible + Handlers + 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. + + + + + +

Called by an approver to accept a channel bundle and request that + the given handler be used to handle it.

+ +

If successful, this method will cause the ChannelDispatchOperation + object to disappear, emitting + Finished.

+ +

However, this method may fail because the dispatch has already been + completed and the object has already gone. If this occurs, it + indicates that another approver has asked for the bundle to be + handled by a particular handler. The approver MUST NOT attempt + to interact with the channels further in this case, unless it is + separately invoked as the handler.

+ +

Approvers which are also channel handlers SHOULD use Claim instead + of HandleWith to request that they can handle a channel bundle + themselves.

+ +

(FIXME: list some possible errors)

+ +

If the channel handler raises an error from Handle, this method + MAY respond by raising that same error, even if it is not + specifically documented here.

+ + + + +

The well-known bus name (starting with + org.freedesktop.Telepathy.Client.) of the channel + handler that should handle the channel.

+ + + + + + + The selected handler is not a syntactically correct + DBus_Bus_Name or does not start with + "org.freedesktop.Telepathy.Client.". + + + + + The selected handler is temporarily unable to handle these + channels. + + + + + The selected handler is syntactically correct, but will never + be able to handle these channels (for instance because the channels + do not match its HandlerChannelFilter, or because HandleChannels + raised NotImplemented). + + + + + At the time that HandleWith was called, this dispatch operation was + processing an earlier call to HandleWith. The earlier call has + now succeeded, so some Handler nominated by another approver is + now responsible for the channels. In this situation, the second + call to HandleWith MUST NOT return until the first one has + returned successfully or unsuccessfully, and if the first call + to HandleChannels fails, the channel dispatcher SHOULD try to obey + the choice of Handler made by the second call to HandleWith. + + + + + + + +

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 + does not have the HandleChannels method called on it.

+ + +

Clients that call Claim on channels but do not immediately + close them SHOULD implement the Handler interface and its + CurrentlyHandledChannels property.

+ + +

Approvers wishing to reject channels MUST call this method to + claim ownership of them, and MUST NOT call + Close + on the channels unless/until this method returns successfully.

+ + +

The channel dispatcher can't know how best to close arbitrary + channel types, so it leaves it up to the approver to do so. + 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.

+ + +

If successful, this method will cause the ChannelDispatchOperation + object to disappear, emitting + Finished, in the same way as for + HandleWith.

+ +

This method may fail because the dispatch operation has already + been completed. Again, see HandleWith for more details. The approver + MUST NOT attempt to interact with the channels further in this + case.

+ +

(FIXME: list some other possible errors)

+ + + + + + At the time that Claim was called, this dispatch operation was + processing a call to HandleWith which has now succeeded, so + some Handler nominated by another approver is now responsible for + the channel. + + + + + + + +

Emitted when this dispatch operation finishes. The dispatch + operation is no longer present and further methods must not be + called on it.

+ +

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.

+ + +

Otherwise, clients might accidentally call HandleWith or Claim + on a new dispatch operation instead of the one they + intended to handle.

+ + + + + + + diff --git a/spec/Channel_Dispatcher.xml b/spec/Channel_Dispatcher.xml new file mode 100644 index 000000000..822e7dd9a --- /dev/null +++ b/spec/Channel_Dispatcher.xml @@ -0,0 +1,222 @@ + + + + Copyright (C) 2008 Collabora Ltd. + Copyright (C) 2008 Nokia Corporation + +

This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version.

+ +

This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details.

+ +

You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, + USA.

+ + + + + +

The channel dispatcher is responsible for responding to new + channels and launching client processes to handle them. It also + provides functionality for client processes to request that new + channels are created.

+ +

If a channel dispatcher is running, it is responsible for dispatching + new channels on all + Connections + created by the + AccountManager. + Connections not created by the AccountManager are outside the scope + of the channel dispatcher.

+ + +

Connections created by standalone Telepathy clients + that do not intend to interact with the channel dispatcher + should be ignored - otherwise, the channel dispatcher would try + to launch handlers for channels that the standalone client + was already handling internally.

+ + +

The current channel dispatcher is defined to be the process that + owns the well-known bus name + org.freedesktop.Telepathy.ChannelDispatcher on + the session bus. This process MUST export an object with this + interface at the object path + /org/freedesktop/Telepathy/ChannelDispatcher.

+ +

Until a mechanism exists for making a reasonable automatic choice + of ChannelDispatcher implementation, implementations SHOULD NOT + register as an activatable service for the ChannelDispatcher's + well-known bus name. Instead, it is RECOMMENDED that some component + of the user's session will select and activate a particular + implementation, and that other Telepathy-enabled programs + can detect whether channel request/dispatch functionality is available + by checking whether the ChannelDispatcher's well-known name is in use + at runtime.

+ +

There are three categories of client process defined by this + specification:

+ +
+
Observer
+

Observers monitor the creation of new channels. This + functionality can be used for things like message logging. + All observers are notified simultaneously.

+ +
Approver
+
+

Approvers notify the user that new channels have been created, + and also select which channel handler will be used for the channel, + either by asking the user or by choosing the most appropriate + channel handler.

+
+ +
Handler
+
+

Each new channel or set of channels is passed to exactly one + handler as its final destination. A typical channel handler is a + user interface process handling channels of a particular type.

+
+
+ + + + + A list of the extra interfaces provided by this channel dispatcher. + + + + + +

Start a request to create a channel. This initially just creates a + ChannelRequest.DRAFT + object, which can be used to continue the request and track its + success or failure.

+ + +

The request can take a long time - in the worst case, the + channel dispatcher has to ask the account manager to put the + account online, the account manager has to ask the operating + system to obtain an Internet connection, and the operating + system has to ask the user whether to activate an Internet + connection using an on-demand mechanism like dialup.

+ +

This means that using a single D-Bus method call and response + to represent the whole request will tend to lead to that call + timing out, which is not the behaviour we want.

+ + +

If this method is called for an Account that is disabled, invalid + or otherwise unusable, no error is signalled until + ChannelRequest.DRAFT.Proceed + is called, at which point + ChannelRequest.DRAFT.Failed + is emitted with an appropriate error.

+ + +

This means there's only one code path for errors, apart from + InvalidArgument for "that request makes no sense".

+ +

It also means that the request will proceed if the account is + enabled after calling CreateChannel, but before calling + Proceed.

+ + + + + + The + Account + for which the new channel is to be created. + + + + + +

A dictionary containing desirable properties. This has the same + semantics as the corresponding parameter to + Connection.Interface.Requests.CreateChannel. +

+ +

Certain properties will not necessarily make sense in this + dictionary: for instance, + TargetHandle + can only be given if the requester is able to interact with a + Connection + to the desired account.

+ + + + + +

The time at which user action occurred, or 0 if this channel + request is for some reason not involving user action. + The UserActionTime + property will be set to this value.

+ + + + + +

Either the well-known bus name (starting with + org.freedesktop.Telepathy.Client.) + of the preferred handler for this + channel, or an empty string to indicate that any handler would be + acceptable. The channel dispatcher SHOULD dispatch as many as + possible of the resulting channels (ideally, all of them) + to that handler, and SHOULD remember the preferred handler + so it can try to dispatch subsequent channels in the same bundle + to the same handler.

+ + +

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.

+ +

This is partly so the channel dispatcher can call + HandleChannel on it, and partly so the channel dispatcher + can recover state if it crashes and is restarted.

+ + + + + + + A + ChannelRequest.DRAFT + object. + + + + + + + The Preferred_Handler is syntactically invalid or does + not start with org.freedesktop.Telepathy.Client., + the Account does not exist, or one of the Requested_Properties + is invalid + + + + + + + + + diff --git a/spec/Channel_Dispatcher_Interface_Operation_List.xml b/spec/Channel_Dispatcher_Interface_Operation_List.xml new file mode 100644 index 000000000..40cd86e54 --- /dev/null +++ b/spec/Channel_Dispatcher_Interface_Operation_List.xml @@ -0,0 +1,138 @@ + + + + Copyright (C) 2008 Collabora Ltd. + Copyright (C) 2008 Nokia Corporation + +

This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version.

+ +

This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details.

+ +

You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, + USA.

+ + + + + + + +

This interface allows users of the ChannelDispatcher to enumerate + all the pending dispatch operations, with change notification.

+ + +

The existence of the DispatchOperations property allows a newly + started approver to pick up existing dispatch operations.

+ +

This is on a separate interface so clients that aren't interested + in doing this aren't woken up by its signals.

+ + + + + + + Details of a channel dispatch operation. + + + + + The object path of the + ChannelDispatchOperation. + + + + + +

Properties of the channel dispatch operation.

+ +

Connection managers MUST NOT include properties in this mapping + if their values can change. Clients MUST ignore properties + that appear in this mapping if their values can change.

+ + +

The rationale is the same as for + Channel_Details.

+ + +

Each dictionary MUST contain at least the following keys:

+
    +
  • org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT.Interfaces
    • +
  • org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT.Connection
    • +
  • org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT.Account
    • +
  • org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT.Channels
    • +
  • org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT.PossibleHandlers
    • +
+ + + + + + +

The list of ChannelDispatchOperation objects currently being + processed. Change notification is via the NewDispatch and + DispatchFinished signals.

+ + + + + +

Emitted when a dispatch operation is added to + DispatchOperations.

+ + + + + The dispatch operation that was created. + + + + + + The same properties that would appear in the Properties member of + Dispatch_Operation_Details. + + + + + + + Emitted when a dispatch operation finishes (i.e. exactly once per + emission of ChannelDispatchOperation.DRAFT.Finished). + + + Strictly speaking this is redundant with + ChannelDispatchOperation.Finished, but it provides full + change-notification for the DispatchOperations property. + + + + + + The dispatch operation that was closed. + + + + + + + diff --git a/spec/Channel_Interface_Call_State.xml b/spec/Channel_Interface_Call_State.xml index 132137eda..0df6e3472 100644 --- a/spec/Channel_Interface_Call_State.xml +++ b/spec/Channel_Interface_Call_State.xml @@ -101,6 +101,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + + + + The initiator of the call originally called a contact other than the + current recipient of the call, but the call was then forwarded or + diverted. + + diff --git a/spec/Channel_Interface_Destroyable.xml b/spec/Channel_Interface_Destroyable.xml new file mode 100644 index 000000000..2f82e6980 --- /dev/null +++ b/spec/Channel_Interface_Destroyable.xml @@ -0,0 +1,79 @@ + + + Copyright (C) 2008 Collabora Ltd. + Copyright (C) 2008 Nokia Corporation + + +

This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version.

+ +

This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details.

+ +

You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, + USA.

+ + + + + (draft, not API-stable) + + +

This interface exists to support channels where + Channel.Close + is insufficiently destructive.

+ + + + +

Close the channel abruptly, possibly with loss of data. The + connection manager MUST NOT re-create the channel unless/until + more events occur.

+ + +

The main motivating situation for this method is that when a Text + channel with pending messages is closed with Close, it comes back + as an incoming channel (to avoid a race between Close and an + incoming message). If Destroy is called on a Text channel, the CM + should delete all pending messages and close the channel, and + the channel shouldn't be re-created until/unless another message + arrives.

+ + +

Most clients SHOULD call + Channel.Close + instead. However, if a client explicitly intends to destroy the + channel with possible loss of data, it SHOULD call this method + if this interface is supported (according to the + Channel.Interfaces + property), falling back to Close if not.

+ +

In particular, channel dispatchers SHOULD use this method if + available when terminating channels that cannot be handled + correctly (for instance, if no handler has been installed for + a channel type, or if the handler crashes repeatedly).

+ +

Connection managers do not need to implement this interface on + channels where Close and Destroy would be equivalent.

+ + +

Callers need to be able to fall back to Close in any case.

+ + + + + + + diff --git a/spec/Channel_Request.xml b/spec/Channel_Request.xml new file mode 100644 index 000000000..25f5b066c --- /dev/null +++ b/spec/Channel_Request.xml @@ -0,0 +1,178 @@ + + + + Copyright (C) 2008 Collabora Ltd. + Copyright (C) 2008 Nokia Corporation + +

This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version.

+ +

This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details.

+ +

You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + MA 02110-1301, USA.

+ + + + + +

A channel request is an object in the ChannelDispatcher representing + an ongoing request for some channels to be created or found. There + can be any number of ChannelRequest objects at the same time.

+ +

Its well-known bus name is the same as that of the ChannelDispatcher, + "org.freedesktop.Telepathy.ChannelDispatcher".

+ + +

See + ChannelDispatcher.DRAFT.CreateChannel + for rationale for ChannelRequest being a separate object.

+ + + + + +

The time at which user action occurred, or 0 if this channel + request is for some reason not involving user action.

+ +

This corresponds to the _NET_WM_USER_TIME property in + EWMH.

+ +

This property is set when the channel request is created, + and can never change.

+ + + + + +

An array of dictionaries containing desirable properties for + the channel or channels to be created.

+ + +

This is an array so that we could add a CreateChannels method in + future without redefining the API of ChannelRequest.

+ + +

This property is set when the channel request is created, + and can never change.

+ + + + + +

Proceed with the channel request.

+ + +

The client that created this object calls this method + when it has connected signal handlers for + Succeeded and + Failed.

+ + +

Clients other than the client which created the ChannelRequest + MUST NOT call this method.

+ +

This method SHOULD return immediately; on success, the request + might still fail, but this will be indicated asynchronously + by the Failed signal.

+ +

Proceed cannot fail, unless clients have got the life-cycle + of a ChannelRequest seriously wrong (e.g. a client calls this + method twice, or a client that did not create the ChannelRequest + calls this method). If it fails, clients SHOULD assume that the + whole ChannelRequest has become useless.

+ + + + + + This method has already been called, so it is no longer + available. Stop calling it. + + + + + + + +

Cancel the channel request. The precise effect depends on the + current progress of the request.

+ +

If the connection manager has not already been asked to create + a channel, then Failed is emitted + immediately, and the channel request is removed.

+ +

If the connection manager has already been asked to create a + channel but has not produced one yet (e.g. if Connection.Interface.Requests.CreateChannel + has been called, but has not yet returned), then the + ChannelDispatcher will remember that the request has been cancelled. + When the channel appears, it will be closed (if it was newly + created and can be closed), and will not be dispatched to a + handler.

+ +

If the connection manager has already returned a channel, but the + channel has not yet been dispatched to a handler + (e.g. if Connection.Interface.Requests.CreateChannel + has returned a channel, but the dispatch operation is waiting for + approvers) then the channel dispatcher will not dispatch that + channel to a handler. If the channel was newly created for this + request, the channel dispatcher will close it with Close; otherwise, + the channel dispatcher will ignore it. In either case, + Failed will be emitted when processing + has been completed.

+ +

If Failed is emitted in response to this method, the error SHOULD be + org.freedesktop.Telepathy.Errors.Cancelled.

+ +

If the channel has already been dispatched to a handler, then + it's too late to call this method, and the channel request will + no longer exist.

+ + + + + +

The channel request has failed. It is no longer present, + and further methods must not be called on it.

+ + + + +

The name of a D-Bus error. This can come from various sources, + including the error raised by CreateChannel, or an error generated + to represent failure to establish the Connection.

+ + + + + + If the first argument of the D-Bus error message was a string, + that string. Otherwise, an empty string. + + + + + + +

The channel request has succeeded. It is no longer present, + and further methods must not be called on it.

+ + + + + + diff --git a/spec/Client.xml b/spec/Client.xml new file mode 100644 index 000000000..da3cfbef4 --- /dev/null +++ b/spec/Client.xml @@ -0,0 +1,123 @@ + + + Copyright (C) 2008 Collabora Ltd. + Copyright (C) 2008 Nokia Corporation + +

This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version.

+ +

This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details.

+ +

You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + 02110-1301, USA.

+ + + + + + +

Telepathy clients use connection managers, the channel dispatcher + and optionally the account manager to provide useful + functionality.

+ +

User interface processes are the obvious example of Telepathy + clients, but they can provide other functionality, such as + address-book synchronization.

+ +

Every running or activatable process with a well-known + name of the form org.freedesktop.Telepathy.Client.clientname + should be probed by the channel dispatcher to discover its + capabilities. Each client is either an observer, an + approver, a channel handler, or some combination + of these.

+ + +

Activatable services (those with a D-Bus .service + file) must be supported so that we can run clients + in response to channel creation.

+ +

Non-activatable services (those that do not register a D-Bus + .service 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.

+ + +

The client name, clientname, 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.

+ + +

If each of a client Foo's instances should be able to manipulate + channels separately, the instance with unique name + :1.25 might request a well-known name like + org.freedesktop.Telepathy.Client.Foo._1._25.

+ +

(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.)

+ + +

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.

+ +

As an optimization, activatable clients SHOULD install a file + $XDG_DATA_DIRS/telepathy/clients/clientname.client + 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.

+ +

Non-activatable clients MAY install a .client file, + but there's not much point in them doing so.

+ +

The .client files MUST contain UTF-8 text with the same syntax + as + Desktop + Entry files (although the allowed groups, keys and values differ). + Every .client file MUST contain a group whose name is + the name of this interface.

+ +

The groups, keys and values in the .client file are + defined by individual interfaces. Each interface that can usefully + cache information in the .client file SHOULD correspond + to a group with the same name.

+ + + + +

A list of the extra interfaces provided by this client. + This SHOULD include at least one of + Client.Observer, + Client.Approver or + Client.Handler.

+ +

In the .client file, this is represented by key + "Interfaces" 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.

+ + + + + + diff --git a/spec/Client_Approver.xml b/spec/Client_Approver.xml new file mode 100644 index 000000000..c912b128c --- /dev/null +++ b/spec/Client_Approver.xml @@ -0,0 +1,135 @@ + + + Copyright (C) 2008 Collabora Ltd. + Copyright (C) 2008 Nokia Corporation + +

This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version.

+ +

This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details.

+ +

You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + 02110-1301, USA.

+ + + + + + + + +

Approvers notify the user that new channels have been created, + and allow the user to accept or reject those channels.

+ +

They can also select which channel handler will be used for the + channel, for instance by offering the user a list of possible + handlers rather than just an accept/reject choice.

+ +

However, the Channel Dispatcher must be able to prioritize + possible handlers on its own using some reasonable heuristic, + probably based on user configuration.

+ +

It is possible (and useful) to have an approver and + a channel handler in the same process; this is particularly useful + if a channel handler wants to claim responsibility for particular + channels itself.

+ +

All approvers are notified simultaneously. For instance, in a + desktop system, there might be one approver that displays a + notification-area icon, one that is part of a contact list + window and highlights contacts there, and one that is part + of a full-screen media player.

+ +

Any approver can approve the handling of a channel with a + particular channel handler. Approvers can also request that the + channel is rejected. The first approver to reply gets its decision + acted on; any other approvers that reply at the same time will + get a D-Bus error, indicating that the channel has already been + dealt with.

+ +

Approvers should usually prompt the user and ask for + confirmation, rather than dispatching the channel to a handler + straight away.

+ + + + +

A specification of the channels in which this approver is + interested. The AddDispatchOperation + method should be called by the channel dispatcher whenever the + channels in a channel dispatch operation + match this description.

+ +

(FIXME: what happens if some but not all of the channels + match this?)

+ +

This property works in exactly the same way as the + Client.Observer.DRAFT.ObserverChannelFilter + property. In the .client file, it is represented in the + same way as ObserverChannelFilter, but the group has the same + name as this interface and the keys start with + ApproverChannelFilter instead of ObserverChannelFilter.

+ + + + + +

Called by the channel dispatcher when a ChannelDispatchOperation + in which the approver has registered an interest is created.

+ +

The channel dispatcher SHOULD call this method on all approvers + at the same time. If no approvers return from this method + successfully (including situations where there are no matching + approvers at all), the channel dispatcher SHOULD consider this + to be an error, and recover by dispatching the channel to the + most preferred handler.

+ + + Processes that aren't approvers shouldn't be making connections + anyway - there should always be at least one approver running. + + + + + +

The + ChannelDispatchOperation + to be processed.

+ + + + + + Properties of the channel dispatch operation. This MUST NOT include + properties that could change, SHOULD include as many properties as + possible given that constraint, and MUST include at least the + Account, + Connection, + Channels + and + PossibleHandlers + properties. + + + + + + + diff --git a/spec/Client_Handler.xml b/spec/Client_Handler.xml new file mode 100644 index 000000000..4e815d030 --- /dev/null +++ b/spec/Client_Handler.xml @@ -0,0 +1,268 @@ + + + Copyright (C) 2008 Collabora Ltd. + Copyright (C) 2008 Nokia Corporation + +

This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version.

+ +

This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details.

+ +

You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + 02110-1301, USA.

+ + + + + + + + +

Channel handlers are the eventual handler for a channel or a + channel bundle; a typical channel handler is a user interface + process handling channels of a particular type.

+ +

When a new incoming channel (one with + Requested + = TRUE) is offered to + Approvers + by the channel dispatcher, it also offers the Approvers a list of all + the running or activatable ChannelHandlers whose + HandlerChannelFilter property + (possibly as cached in the .client file) indicates that they + are able to handle the channel. The Approvers can choose one of + those channel handlers to handle the channel.

+ +

When a new outgoing channel (one with + Requested + = FALSE) appears, the channel dispatcher passes it to an appropriate + channel handler automatically. +

+ + + + + +

A specification of the channels that this channel handler can + deal with. It will be offered to approvers as a potential + channel handler for bundles that contain only suitable channels, + or for suitable channels that must be handled separately.

+ +

This property works in exactly the same way as the + Client.Observer.DRAFT.ObserverChannelFilter + property. In the .client file, it is represented in the + same way as ObserverChannelFilter, but the group has the same + name as this interface and the keys start with + HandlerChannelFilter instead of ObserverChannelFilter.

+ + + + + +

If true, channels destined for this handler are automatically + handled, without invoking approvers.

+ + +

The intended usage is to allow a client handling one channel to + pick up closely related channels. Suppose a client capable of + handling both Text and StreamedMedia, + org.freedesktop.Telepathy.Client.Empathy, is + handling a StreamedMedia channel. That client can take a second + well-known bus name, say + org.freedesktop.Telepathy.Client.Empathy._1._42.Bundle1, + and configure an object at + /org/freedesktop/Telepathy/Client/Empathy/_1/_42/Bundle1 + with BypassApproval = TRUE, + whose HandlerChannelFilter + matches closely related Text channels by their Bundle property. + (This is use-case dis5)

+ + + + + + +

Called by the channel dispatcher when this client should handle these + channels, or when this client should present channels that it is already + handling to the user (e.g. bring them into the foreground).

+ + +

Clients are expected to know what channels they're already handling, + and which channel object path corresponds to which window or tab. + This can easily be done using a hash table keyed by channels' object + paths.

+ + +

This method can raise any D-Bus error. If it does, or if the + handler loses its bus name before all the channels have closed, the + handler is assumed to have failed or crashed, and the channel + dispatcher MUST recover in an implementation-specific way.

+ +

It is RECOMMENDED that the channel dispatcher attempts to + close the channels using + Channel.Close, + but resorts to calling + Channel.Interface.Destroyable.DRAFT.Destroy + (if available) or ignoring the channel (if not) if the same handler + repeatedly fails to handle channels.

+ + + + + The + Account + with which the channels are associated. The + well-known bus name to use is that of the + AccountManager. + + + + + + The Connection with which the channels are associated. The + well-known bus name to use can be derived from this object + path by removing the leading '/' and replacing all subsequent + '/' by '.'. + + + + + + The channels and their immutable properties. Their well-known + bus name is the same as that of the Connection. + + + + + + The requests satisfied by these channels. + + + There can be more than one, if they were EnsureChannel + requests. + + + + + + + The time at which user action occurred, or 0 if this channel + is to be handled for some reason not involving user action. + Handlers SHOULD use this for focus-stealing prevention, + if applicable. + + + + + + + + +

Called by the ChannelDispatcher to indicate that channels have been + requested, and that if the request is successful, they will be + handled by this Handler.

+ + +

This allows the UI to start preparing to handle the channels + in advance (e.g. render a window with an "in progress" message), + improving perceived responsiveness.

+ + +

(FIXME: how do we know the returned channels will be handled by + this handler? Do we just assume that they'll match the + HandlerChannelFilter iff the request does?)

+ + + + + The ChannelRequest + object. + + + + + +

Some of the properties of the ChannelRequest. To avoid race + conditions, this dictionary MUST NOT include properties whose + values could subsequently change. It SHOULD include as many + properties as possible, given that constraint.

+ +

In particular, the properties Requests and UserActionTimestamp + MUST be included.

+ + + + + + +

Called by the ChannelDispatcher to indicate that a request + previously passed to AddRequest + has failed and should be disregarded.

+ + + + + The request that failed. + + + + + +

The name of the D-Bus error with which the request failed.

+ +

If this is org.freedesktop.Telepathy.Errors.NotYours, + this indicates that the request succeeded, but all the resulting + channels were given to some other handler.

+ + + + + + Any message supplied with the D-Bus error. + + + + + + +

A list of the channels that this Handler is currently handling. +

+ +

There is no change notification.

+ + +

This property exists for state recovery - it makes it possible + for channel handling to survive a ChannelDispatcher crash.

+ +

If the channel dispatcher is automatically replaced, the + replacement can discover all Handlers by looking for the Client + well-known bus names, and discover which channels they are + currently handling. Once this has been done, all unhandled + channels can be re-dispatched, and the only issue visible to + the user is that unhandled channels that they have already + approved might be sent back to Approvers.

+ + + + + + + diff --git a/spec/Client_Observer.xml b/spec/Client_Observer.xml new file mode 100644 index 000000000..eccbefdcc --- /dev/null +++ b/spec/Client_Observer.xml @@ -0,0 +1,230 @@ + + + Copyright (C) 2008 Collabora Ltd. + Copyright (C) 2008 Nokia Corporation + +

This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version.

+ +

This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details.

+ +

You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + 02110-1301, USA.

+ + + + + + + + +

Observers monitor the creation of new channels. This + functionality can be used for things like message logging. + All observers are notified simultaneously.

+ +

Observers SHOULD NOT modify the state of a channel except + via user interaction.

+ + +

We want Observer UIs for file transfer channels (a progress + bar for the transfer) to be able to have a Cancel button.

+ + +

Observers MUST NOT carry out actions that exactly one process + must take responsibility for (e.g. acknowledging Text + messages, or carrying out the actual transfer in a file transfer + channel).

+ + +

Since arbitrarily many observers can be activated for + each channel, it would not make sense for observers to do things + that can only be done by one process (acknowledging + Text + messages, carrying out streaming for + StreamedMedia + channels, doing the actual data transfer for file transfers, + setting up the out-of-band connection for Tubes). The + Handler + is responsible for such tasks.

+ +

Handlers MAY, of course, delegate responsibility for these + tasks to other processes (including those run as observers), + but this MUST be done explicitly via a request from the Handler + to the Observer.

+ + +

Whenever new channels are signalled, the channel dispatcher + will notify all running or activatable observers whose + ObserverChannelFilter property + (possibly as cached in the .client file) indicates that they are + interested in the channel.

+ +

Observers are activated for all channels in which they have + registered an interest - incoming, outgoing or automatically created - + although of course the ObserverChannelFilter property can be set + to filter on the + Channel.FUTURE.Requested + property.

+ + + + +

A specification of the channels in which this observer is + interested. The ObserveChannels method + should be called by the channel dispatcher whenever any of the new + channels in a NewChannels signal match this description.

+ +

(FIXME: open issue: do we want this, and the corresponding + Approver and Handler properties, to be able to change at + runtime?)

+ +

Only certain D-Bus types have useful semantics for matching like this, + so only certain types are allowed:

+ +
+
Integers of all sizes, including byte (y, n, q, i, u, x, t)
+
Matched by numeric value, regardless of type (e.g. 42 as a + 16-bit signed integer 'n' is considered equal to 42 as a 32-bit + unsigned integer 'u')
+ +
Booleans (b)
+
Matched by equality in the obvious way; not considered equal to any + other type
+ +
Strings (s)
+
Matched by equality in the obvious way; not considered equal to any + other type
+ +
Object paths (o)
+
Matched by equality in the obvious way; not considered equal to any + other type
+ +
+ +

This property never changes while the observer process is + running. For activatable processes, the filter can change due to an + upgrade - the channel dispatcher SHOULD observe changes to .client files + using a mechanism like inotify.

+ +

For observers that have a .client file, the channel dispatcher + may discover this property from keys of the form + propertyname/type, + in groups in the .client file whose name is the name of this + interface followed by .ObserverChannelFilter, + a space and an ASCII decimal number starting from 0.

+ +

Integers in the .client file are encoded in ASCII decimal, booleans + are encoded as "true" or "false", and strings are encoded in the usual + way for desktop files (including the C-style backslash escapes + documented in the Desktop Entry specification).

+ +

For instance, a .client file for an observer that is only interested + in Text channels, with CONTACT or ROOM handles, that were requested by + a local client:

+ +
+[org.freedesktop.Telepathy.Client.DRAFT]
+Interfaces=org.freedesktop.Telepathy.Client.Observer.DRAFT;
+
+[org.freedesktop.Telepathy.Client.Observer.DRAFT.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.FUTURE.Requested b=true
+
+[org.freedesktop.Telepathy.Client.Observer.DRAFT.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.FUTURE.Requested b=true
+
+ + + + + + +

Called by the channel dispatcher when channels in which the + observer has registered an interest are created.

+ +

The observer MUST NOT return from this method call until it is ready + for a handler for the channel to run (which may change the channel's + state).

+ + +

The channel dispatcher must wait for observers to start up, + to avoid the following race: text channel logger (observer) gets + ObserveChannel, text channel handler gets + HandleChannels + channel handler starts up faster and acknowledges messages, + logger never sees those messages.

+ + + + + + The + Account + with which the channels are associated. The + well-known bus name to use is that of the + AccountManager. + + + + + + The + Connection + with which the channels are associated. The + well-known bus name to use can be derived from this object + path by removing the leading '/' and replacing all subsequent + '/' by '.'. + + + + + +

The + Channels + and their properties. Their well-known bus names are all the same + as that of the Connection.

+ + +

The ChannelDispatchOperation is not supplied: for + requests, there isn't one, and for incoming channels, it hasn't + been created yet.

+ + + + + + +

Additional information about these channels. No keys are + currently defined.

+ +

If keys are defined for this dictionary, all will be optional; + observers MAY safely ignore any entry in this dictionary.

+ + + + + + + + diff --git a/spec/Makefile.am b/spec/Makefile.am index ea5282522..83c57ef1b 100644 --- a/spec/Makefile.am +++ b/spec/Makefile.am @@ -3,12 +3,16 @@ EXTRA_DIST = \ Account_Manager.xml \ Account.xml \ all.xml \ + Channel_Dispatch_Operation.xml \ + Channel_Dispatcher.xml \ + Channel_Dispatcher_Interface_Operation_List.xml \ Channel_Future.xml \ Channel_Handler.xml \ Channel_Interface_Call_Merging.xml \ Channel_Interface_Call_State.xml \ Channel_Interface_Chat_State.xml \ Channel_Interface_Delivery_Reporting.xml \ + Channel_Interface_Destroyable.xml \ Channel_Interface_DTMF.xml \ Channel_Interface_Group.xml \ Channel_Interface_Hold.xml \ @@ -17,6 +21,7 @@ EXTRA_DIST = \ Channel_Interface_Messages.xml \ Channel_Interface_Password.xml \ Channel_Interface_Transfer.xml \ + Channel_Request.xml \ Channel_Type_Contact_List.xml \ Channel_Type_Contact_Search.xml \ Channel_Type_Room_List.xml \ @@ -24,6 +29,10 @@ EXTRA_DIST = \ Channel_Type_Text.xml \ Channel_Type_Tubes.xml \ Channel.xml \ + Client.xml \ + Client_Approver.xml \ + Client_Handler.xml \ + Client_Observer.xml \ Connection_Interface_Aliasing.xml \ Connection_Interface_Avatars.xml \ Connection_Interface_Capabilities.xml \ diff --git a/spec/all.xml b/spec/all.xml index d60f9e398..a9c58c113 100644 --- a/spec/all.xml +++ b/spec/all.xml @@ -3,7 +3,7 @@ xmlns:xi="http://www.w3.org/2001/XInclude"> Telepathy D-Bus Interface Specification -0.17.11 +0.17.12 Copyright (C) 2005-2008 Collabora Limited Copyright (C) 2005-2008 Nokia Corporation @@ -31,14 +31,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. - - - @@ -47,8 +41,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. - @@ -58,13 +50,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + - @@ -77,9 +68,30 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + + + + + + + + + + + + + + + + diff --git a/spec/errors.xml b/spec/errors.xml index 81ab440e7..679e3f4e2 100644 --- a/spec/errors.xml +++ b/spec/errors.xml @@ -1,5 +1,8 @@ + Raised when there is an error reading from or writing to the network. @@ -60,8 +63,22 @@ - Copyright (C) 2005, 2006, 2007 Collabora Limited - Copyright (C) 2005, 2006, 2007 Nokia Corporation + + + The requested channel or other resource already exists, and another + client is responsible for it + + + + + + Raised by an ongoing request if it is cancelled by user request before + it has completed. + + + + Copyright (C) 2005-2008 Collabora Limited + Copyright (C) 2005-2008 Nokia Corporation

This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public diff --git a/spec/generic-types.xml b/spec/generic-types.xml index 480b2c958..9d8501de9 100644 --- a/spec/generic-types.xml +++ b/spec/generic-types.xml @@ -67,7 +67,8 @@ "org.freedesktop.DBus.Peer.Ping". - + A mapping from strings representing D-Bus properties (by their namespaced names) to their values. diff --git a/telepathy-glib/Makefile.am b/telepathy-glib/Makefile.am index ae2993e50..741290bef 100644 --- a/telepathy-glib/Makefile.am +++ b/telepathy-glib/Makefile.am @@ -18,7 +18,8 @@ ABI_LISTS = \ versions/0.7.12.abi \ versions/0.7.13.abi \ versions/0.7.14.abi \ - versions/0.7.15.abi + versions/0.7.15.abi \ + versions/0.7.16.abi EXTRA_DIST = \ $(ABI_LISTS) \ diff --git a/telepathy-glib/channel-manager.c b/telepathy-glib/channel-manager.c index f6b6d71ef..e134fa044 100644 --- a/telepathy-glib/channel-manager.c +++ b/telepathy-glib/channel-manager.c @@ -154,12 +154,14 @@ * @ensure_channel: Respond to a request for a (new or existing) channel made * with the Connection.Interface.Requests.EnsureChannel method. See * #TpChannelManagerRequestFunc for details. - * Since: 0.7.UNRELEASED+1 + * Since: 0.7.16 * * The vtable for a channel manager implementation. * * In addition to the fields documented here there are several GCallback * fields which must currently be %NULL. + * + * Since: 0.7.15 */ @@ -639,7 +641,7 @@ tp_channel_manager_request_channel (TpChannelManager *manager, * * Returns: %TRUE if this request will be handled by @manager; else %FALSE. * - * Since: 0.7.UNRELEASED+1 + * Since: 0.7.16 */ gboolean tp_channel_manager_ensure_channel (TpChannelManager *manager, diff --git a/telepathy-glib/connection.c b/telepathy-glib/connection.c index 54c723726..6785bbb5c 100644 --- a/telepathy-glib/connection.c +++ b/telepathy-glib/connection.c @@ -1066,7 +1066,7 @@ get_presence_type_availability (TpConnectionPresenceType type) * * Returns: -1, 0 or 1, if @p1 is <, == or > than @p2. * - * Since: 0.7.UNRELEASED + * Since: 0.7.16 */ gint tp_connection_presence_type_cmp_availability (TpConnectionPresenceType p1, diff --git a/telepathy-glib/versions/0.7.16.abi b/telepathy-glib/versions/0.7.16.abi new file mode 100644 index 000000000..7d2ec51de --- /dev/null +++ b/telepathy-glib/versions/0.7.16.abi @@ -0,0 +1,9 @@ +Version: TELEPATHY_GLIB_0.7.16 +Extends: TELEPATHY_GLIB_0.7.15 +Release: 0.7.16 + +tp_channel_manager_ensure_channel +tp_cli_connection_interface_requests_call_ensure_channel +tp_cli_connection_interface_requests_run_ensure_channel +tp_connection_presence_type_cmp_availability +tp_svc_connection_interface_requests_implement_ensure_channel -- cgit v1.2.3