From 5b60145b258e1682cb2eb16530211cc4e0cb9935 Mon Sep 17 00:00:00 2001
From: Simon McVittie True if this channel was created in response to a local request,
such as a call to
-
The idea of this property is to distinguish between "incoming" @@ -323,7 +323,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Each channel has a number of immutable properties (which cannot vary
after the channel has been announced with
More specifically, whenever the A dictionary containing desirable properties. This has the same
semantics as the corresponding parameter to
- Certain properties will not necessarily make sense in this
@@ -318,7 +318,7 @@
A dictionary containing desirable properties. This has the same
semantics as the corresponding parameter to
- Certain properties will not necessarily make sense in this
@@ -361,7 +361,7 @@
so it can try to dispatch subsequent channels in the same bundle
to the same handler. If the requested channel already exists (that
is, This method may raise any error that would be raised by the
While this seems redundant, since the scheme is included in
Yours=False
) then the channel dispatcher
SHOULD re-dispatch the channel to its existing handler, and MUST
NOT dispatch it to this client (unless it is the existing handler);
diff --git a/spec/Channel_Dispatcher_Interface_Messages1.xml b/spec/Channel_Dispatcher_Interface_Messages1.xml
index 9b92acb..95fd08a 100644
--- a/spec/Channel_Dispatcher_Interface_Messages1.xml
+++ b/spec/Channel_Dispatcher_Interface_Messages1.xml
@@ -126,7 +126,7 @@
- CreateChannel ({
+ CreateChannel ({
...ChannelType : ...Call,
...InitialChannels : [C1, C2]
})
@@ -153,7 +153,7 @@
the room), call:
- EnsureChannel ({
+ EnsureChannel ({
...ChannelType: ...Text,
...TargetHandleType : ...Room,
...TargetID : 'telepathy@conf.example.com',
@@ -204,7 +204,7 @@
TargetHandle of C1 into Cn), then immediately inviting the
TargetHandle of C2, the TargetHandle of C3, etc. into Cn as well.
- Sample Sample RequestableChannelClasses
A GSM connection might advertise the following channel class for
@@ -366,7 +366,7 @@
InitialInviteeHandles and
InitialInviteeIDs are
Allowed_Properties in RequestableChannelClasses , then requests with zero
or one channel paths SHOULD also succeed; otherwise, clients SHOULD
NOT make requests with zero or one paths for this property.
@@ -428,7 +428,7 @@
(as opposed to merging several channels into one new conference
channel), this property SHOULD be requestable, and appear in the allowed
properties in RequestableChannelClasses . Otherwise, this property
SHOULD NOT be requestable, and its value SHOULD always be the empty
list.
@@ -521,7 +521,7 @@
This property SHOULD be requestable, and appear in the allowed
properties in RequestableChannelClasses , in protocols where
invitations can have an accompanying text message.
diff --git a/spec/Channel_Interface_SMS1.xml b/spec/Channel_Interface_SMS1.xml
index 226505d..a4f1d74 100644
--- a/spec/Channel_Interface_SMS1.xml
+++ b/spec/Channel_Interface_SMS1.xml
@@ -102,7 +102,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
This property is immutable (cannot change), and therefore SHOULD
appear wherever immutable properties are reported, e.g. NewChannels signals.
diff --git a/spec/Channel_Interface_Tube1.xml b/spec/Channel_Interface_Tube1.xml
index d97b0ae..d4eeb6a 100644
--- a/spec/Channel_Interface_Tube1.xml
+++ b/spec/Channel_Interface_Tube1.xml
@@ -70,7 +70,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
When requesting a tube with
CreateChannel ,
+ namespace="im.telepathy.v1.Connection">CreateChannel,
this property MUST NOT be included in the request; instead, it is set
when StreamTube1.Offer
@@ -81,7 +81,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
When receiving an incoming tube, this property is immutable and so advertised in the
NewChannels
+ namespace="im.telepathy.v1.Connection">NewChannels
signal.
@@ -93,7 +93,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
When requesting a tube with
CreateChannel ,
+ namespace="im.telepathy.v1.Connection">CreateChannel,
this property MUST NOT be included in the request.
diff --git a/spec/Channel_Request.xml b/spec/Channel_Request.xml
index 7529098..4e52d5b 100644
--- a/spec/Channel_Request.xml
+++ b/spec/Channel_Request.xml
@@ -154,7 +154,7 @@
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
+ namespace="im.telepathy.v1">Connection.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
@@ -191,7 +191,7 @@
The name of a D-Bus error. This can come from various sources,
including the error raised by CreateChannel ,
+ namespace="im.telepathy.v1.Connection">CreateChannel,
or an error generated
to represent failure to establish the Connection .
@@ -322,7 +322,7 @@
tp:type="Qualified_Property_Value_Map">
The same immutable properties of the Channel that would appear
- in a NewChannels signal.
diff --git a/spec/Channel_Type_Call1.xml b/spec/Channel_Type_Call1.xml
index 4c30466..5260e8e 100644
--- a/spec/Channel_Type_Call1.xml
+++ b/spec/Channel_Type_Call1.xml
@@ -75,7 +75,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-CreateChannel ({
+CreateChannel ({
...ChannelType : ...Call1 ,
...TargetHandleType : Contact,
@@ -155,12 +155,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
When an incoming call occurs, something like the following
NewChannels
+ namespace="imt1.Connection">NewChannels
signal will occur:
-NewChannels ([
+NewChannels ([
/im/telepathy/v1/Connection/foo/bar/foo_40bar_2ecom/CallChannel,
{
...ChannelType : ...Requestable channel classes
The RequestableChannelClasses
+ namespace="imt1.Connection">RequestableChannelClasses
for Call1 channels
can be:
diff --git a/spec/Channel_Type_Contact_Search1.xml b/spec/Channel_Type_Contact_Search1.xml
index cfc3a62..9fdab7f 100644
--- a/spec/Channel_Type_Contact_Search1.xml
+++ b/spec/Channel_Type_Contact_Search1.xml
@@ -37,7 +37,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
found.
Connections that support contact search channels SHOULD have an entry
- in RequestableChannelClasses with the ChannelType fixed to this
interface,
@@ -56,7 +56,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Requests for channels of this type need only
optionally specify the Server property
(if it is an allowed property in the connection's RequestableChannelClasses ).
+ namespace='imt1.Connection'>RequestableChannelClasses).
Before searching, the
AvailableSearchKeys property should be
@@ -81,7 +81,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Limit results. If allowed by the
connection manager, clients may specify the "page size" by specifying
Limit when calling
- CreateChannel .
+ CreateChannel .
The client should call the channel's
It does not make sense to request this channel type using EnsureChannel ;
+ namespace="im.telepathy.v1.Connection">EnsureChannel
;
clients SHOULD request channels of this type using
CreateChannel
+ namespace="im.telepathy.v1.Connection">CreateChannel
instead.
@@ -296,7 +296,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
It can be in the NewChannels
+ namespace="im.telepathy.v1.Connection">NewChannels
signal for round-trip reduction.
diff --git a/spec/Channel_Type_DBus_Tube1.xml b/spec/Channel_Type_DBus_Tube1.xml
index 6f7f6f1..4917643 100644
--- a/spec/Channel_Type_DBus_Tube1.xml
+++ b/spec/Channel_Type_DBus_Tube1.xml
@@ -138,7 +138,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
other end.
When requesting a channel with
CreateChannel ,
+ namespace="im.telepathy.v1.Connection">CreateChannel,
this property MUST be included in the request.
@@ -190,7 +190,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
When requesting a channel with
- Connection.Interface.Requests.CreateChannel ,
+ Connection.CreateChannel ,
this property MUST NOT be included in the request.
diff --git a/spec/Channel_Type_File_Transfer1.xml b/spec/Channel_Type_File_Transfer1.xml
index 67ccf11..04258f9 100644
--- a/spec/Channel_Type_File_Transfer1.xml
+++ b/spec/Channel_Type_File_Transfer1.xml
@@ -102,7 +102,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
been created.
This property is mandatory when requesting the channel with the
- Connection.Interface.Requests.CreateChannel
+ Connection.CreateChannel
method. Protocols which do not have a content-type property with file
transfers should set this value to application/octet-stream.
@@ -120,7 +120,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
be set to monkey.pdf.
This property is mandatory when requesting the channel with the
- Connection.Interface.Requests.CreateChannel
+ Connection.CreateChannel
method. This property cannot be empty and MUST be set to a sensible value.
@@ -138,7 +138,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
to the byte.
This property is mandatory when requesting the channel with the
- Connection.Interface.Requests.CreateChannel
+ Connection.CreateChannel
method. If this information isn't provided in the protocol, connection managers MUST set it
to UINT64_MAX.
@@ -151,15 +151,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
The type of the ContentHash property.
This property is optional when requesting the channel with the
- Connection.Interface.Requests.CreateChannel
+ Connection.CreateChannel
method. However, if you wish to include the ContentHash
property you MUST also include this property. If you omit this property from a
- Connection.Interface.Requests.CreateChannel
+ Connection.CreateChannel
method call then its value will be assumed to be File_Hash_Type_None.
For each supported hash type, implementations SHOULD include an entry
in RequestableChannelClasses
+ namespace="im.telepathy.v1.Connection">RequestableChannelClasses
with this property fixed to that hash type. If the protocol supports
offering a file without a content hash, implementations SHOULD list
this property in Allowed in a requestable channel class, mapping hash
@@ -177,7 +177,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
property.
This property is optional when requesting the channel with the
- Connection.Interface.Requests.CreateChannel
+ Connection.CreateChannel
method. Its value MUST correspond to the appropriate type of the
ContentHashType property. If the
ContentHashType property is not set, or set to File_Hash_Type_None,
@@ -192,7 +192,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
channel has been created.
This property is optional when requesting the channel with the
- Connection.Interface.Requests.CreateChannel
+ Connection.CreateChannel
method. If this property was not provided by the remote party, connection managers MUST set it to
the empty string.
@@ -206,7 +206,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
cannot change once the channel has been created
This property is optional when requesting the channel with the
- Connection.Interface.Requests.CreateChannel
+ Connection.CreateChannel
method.
diff --git a/spec/Channel_Type_Room_List1.xml b/spec/Channel_Type_Room_List1.xml
index 91d86ac..5ae45ab 100644
--- a/spec/Channel_Type_Room_List1.xml
+++ b/spec/Channel_Type_Room_List1.xml
@@ -66,7 +66,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Emitted when information about rooms on the server becomes
available. The array contains the room handle (as can be
passed to the CreateChannel
+ namespace="imt1.Connection">CreateChannel
method with TargetHandleType =
HANDLE_TYPE_ROOM), the channel type, and a dictionary
diff --git a/spec/Channel_Type_Server_Authentication1.xml b/spec/Channel_Type_Server_Authentication1.xml
index dcd1e34..d3ebfc6 100644
--- a/spec/Channel_Type_Server_Authentication1.xml
+++ b/spec/Channel_Type_Server_Authentication1.xml
@@ -46,7 +46,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Channels of this type cannot be requested with methods such as
CreateChannel .
+ namespace="imt1.Connection">CreateChannel.
They always have Requested = False,
TargetHandleType
= None and TargetHandle
= 0, and cannot be requested with methods such as CreateChannel .
+ namespace="im.telepathy.v1.Connection">CreateChannel.
Also, they SHOULD be dispatched while the
Connection
owning them is in the CONNECTING state.
diff --git a/spec/Channel_Type_Stream_Tube1.xml b/spec/Channel_Type_Stream_Tube1.xml
index 1081de2..7b192cc 100644
--- a/spec/Channel_Type_Stream_Tube1.xml
+++ b/spec/Channel_Type_Stream_Tube1.xml
@@ -246,7 +246,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
When the tube is offered, the service name is transmitted to the
other end.
When requesting a channel with
- Connection.Interface.Requests.CreateChannel ,
+ Connection.CreateChannel ,
this property MUST be included in the request.
@@ -286,7 +286,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
access control.
When requesting a channel with
- Connection.Interface.Requests.CreateChannel ,
+ Connection.CreateChannel ,
this property MUST NOT be included in the request.
diff --git a/spec/Channel_Type_Text.xml b/spec/Channel_Type_Text.xml
index cebc2ec..5c1707a 100644
--- a/spec/Channel_Type_Text.xml
+++ b/spec/Channel_Type_Text.xml
@@ -1494,7 +1494,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
the connection manager MUST allow this, but SHOULD open a new channel
to deliver those messages, signalling it as a new channel with the
NewChannels
+ namespace="imt1.Connection">NewChannels
signal. The new channel should resemble the old channel, but have
Requested = FALSE
regardless of its previous value; the ObserveChannels method
should be called by the channel dispatcher whenever any of the new
channels in a NewChannels
+ namespace="im.telepathy.v1.Connection">NewChannels
signal match this description.
Only certain D-Bus types have useful semantics for matching like this,
@@ -255,7 +255,7 @@ Recover=true
Called by the channel dispatcher when channels in which the
observer has registered an interest are announced in a NewChannels
+ namespace="im.telepathy.v1.Connection">NewChannels
signal.
If the same NewChannels signal announces some channels that match
diff --git a/spec/Connection.xml b/spec/Connection.xml
index 51a2ca7..b4414ca 100644
--- a/spec/Connection.xml
+++ b/spec/Connection.xml
@@ -22,7 +22,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
-
@@ -668,6 +667,540 @@ USA.
+
+ (as stable API)
+
+
+ Enough details of a channel that clients can work out how to dispatch
+ or handle it.
+
+
+
+
+ The object path of the channel.
+
+
+
+
+
+ Properties of the channel.
+
+ 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.
+
+
+ If properties that could change were included, the following
+ race condition would be likely to exist in some cases:
+
+
+ - NewChannels or Get("Channels") includes a property P with
+ value V1
+ - Client creates a proxy object for the channel
+ - The value of P changes to V2
+ - Client connects to PChanged signal
+ - Client should call Get("P") or GetAll here, to avoid the
+ race, but client's author has forgotten to do so
+ - Proxy object thinks P == V1, but actually P == V2
+
+
+ We've taken the opportunity to make the API encourage the
+ client author to get it right. Where possible, we intend that
+ properties whose value will be used in channel dispatching
+ or other "early" processing will be defined so that they are
+ immutable (can never change).
+
+
+ Each dictionary MUST contain the keys
+ im.telepathy.v1.Channel.ChannelType ,
+ im.telepathy.v1.Channel.TargetHandleType ,
+ im.telepathy.v1.Channel.TargetHandle ,
+ im.telepathy.v1.Channel.TargetID
+ and
+ im.telepathy.v1.Channel.Requested .
+
+
+
+ We expect these to be crucial to the channel-dispatching
+ process.
+
+
+
+
+
+
+ (as part of Connection)
+
+
+ Request that an entirely new channel is created.
+
+
+
+
+ A dictionary containing desirable properties, which MUST include
+ ChannelType .
+ Some properties
+ are defined such that only an exact match makes sense, and
+ connection managers MUST NOT satisfy a request with a channel
+ where that property does not match; some properties are defined
+ such that the connection manager MAY treat the request as merely
+ a hint, and make a best-effort attempt to satisfy it. This is
+ documented separately for each property.
+
+ If this dictionary contains a property whose semantics
+ are not known to the connection manager, this method MUST fail
+ without side-effects (in particular it must not create a new
+ channel).
+
+
+ This is necessary if we want to be able to invent properties
+ in future that, when used in a request, are hard requirements
+ rather than just hints. A connection manager that did not know
+ the semantics of those properties could incorrectly return a
+ new channel that did not satisfy the requirements.
+
+
+ The connection manager MUST NOT respond successfully,
+ and SHOULD NOT create a new channel or cause any other
+ side-effects, unless it can create a new channel that satisfies
+ the client's requirements.
+
+ Properties that will be set by this argument need not have write
+ access after the channel has been created - indeed, it is
+ expected that most will be read-only.
+
+
+
+
+
+ The Channel object, which MUST NOT be signalled with
+ NewChannels until after this method
+ returns.
+
+
+ This allows the requester to alter its handling of
+ NewChannels by knowing whether one of the channels satisfied
+ a request it made.
+
+
+
+
+
+
+ Properties of the channel that was produced, equivalent to
+ the properties in Channel_Details .
+ Connection managers MUST NOT include properties here whose
+ values can change, for the same reasons as in
+ Channel_Details .
+
+
+
+
+
+
+
+
+ The channel request was one that can never succeed,
+ such as requesting an unsupported channel type, or requesting
+ a channel type which this connection manager does not support with
+ the given target handle type.
+
+
+
+
+ An invalid handle was requested as the value of a property whose
+ value is a handle (like
+ Channel.TargetHandle ),
+ or a syntactically invalid identifier was requested as the value
+ of a property whose value is the string corresponding to a handle
+ (like Channel.TargetID ).
+
+
+
+
+ The request matched the fixed properties of a
+ Requestable_Channel_Class in
+ RequestableChannelClasses , but the
+ allowed arguments did not make sense; for example, a RoomList1
+ was requested, but the Server
+ property provided was not a valid DNS name.
+
+
+
+
+ The requested channel cannot be created because the requested
+ contact is using a client that lacks a particular feature.
+
+
+
+
+ The requested channel cannot be created because the target is
+ offline.
+
+
+
+
+ The requested channel cannot be created, but in
+ principle, a similar request might succeed in future.
+ For instance, this might be because:
+
+
+ - a channel matching the request already exists and the
+ protocol requires that only one such channel can exist at a
+ time
+ - a channel matching the request has already been requested
+ (by a previous call to CreateChannel,
+
EnsureChannel ,
+ or similar) and the protocol requires that only one such
+ channel can exist at a time
+
+
+
+
+
+
+
+
+
+
+
+ (as part of Connection)
+
+
+ Request that channels are ensured to exist.
+
+
+ The connection manager is in the best position to determine which
+ existing channels could satisfy which requests.
+
+
+
+
+
+
+ A dictionary containing desirable properties, with the same
+ semantics as the corresponding parameter to
+ CreateChannel .
+
+
+
+
+
+ If false, the caller of EnsureChannel MUST assume that some
+ other process is handling this channel; if true, the caller of
+ EnsureChannel SHOULD handle it themselves or delegate it to another
+ client.
+
+ If the creation of a channel makes several calls to EnsureChannel
+ (and no other requests) successful, exactly one of those calls MUST
+ return a true value for this argument.
+
+ If the creation of a channel makes other requests successful,
+ the value returned for this argument MUST be such that exactly
+ one of the clients making requests ends up responsible for the
+ channel. In particular, if
+ CreateChannel returns a channel
+ C, any EnsureChannel calls that also return C
+ MUST return a false value for this argument.
+
+
+
+
+
+ The Channel object. If it was created as a result of this method
+ call, it MUST NOT be signalled by
+ NewChannels until after this method
+ returns.
+
+
+ This allows the requester to alter its handling of
+ NewChannels by knowing whether one of the channels satisfied
+ a request it made.
+
+
+
+
+
+
+ Properties of the channel that was produced, equivalent to
+ the properties in Channel_Details .
+ Connection managers MUST NOT include properties here whose
+ values can change, for the same reasons as in
+ Channel_Details .
+
+
+
+
+
+
+
+
+ The channel request was one that can never succeed,
+ such as requesting an unsupported channel type, or requesting
+ a channel type which this connection manager does not support with
+ the given target handle type.
+
+
+
+
+ An invalid handle was requested as the value of a property whose
+ value is a handle (like
+ Channel.TargetHandle ),
+ or a syntactically invalid identifier was requested as the value
+ of a property whose value is the string corresponding to a handle
+ (like Channel.TargetID ).
+
+
+
+
+ The request matched the fixed properties of a
+ Requestable_Channel_Class in
+ RequestableChannelClasses , but the
+ allowed arguments did not make sense; for example, a RoomList1
+ was requested, but the Server
+ property provided was not a valid DNS name.
+
+
+
+
+ The requested channel cannot be created because the requested
+ contact is using a client that lacks a particular feature.
+
+
+
+
+ The requested channel cannot be created because the target is
+ offline.
+
+
+
+
+ The requested channel cannot be created, but in
+ principle, a similar request might succeed in future.
+
+
+
+
+
+
+
+
+
+
+ (as part of Connection)
+
+
+ A new channel has been created. The connection manager
+ SHOULD emit a single signal for each channel created.
+
+ For example, joining a MUC Tube in XMPP requires joining the
+ corresponding MUC (chatroom). Either the connection manager
+ should announce a new Text channel
+ separately, or not expose the Text channel on the bus
+ until it's actually requested (or an incoming message
+ appears).
+
+
+ Signalling the creation of multiple channels together
+ makes writing simple clients much more complicated, can
+ result in lost messages, and isn't nearly as useful in
+ practice as it sounds.
+
+
+
+
+
+ The channels and their details.
+
+
+
+
+
+ (as stable API)
+
+ A list of all the channels which currently exist on this connection.
+ Change notification is via the
+ NewChannels and
+ ChannelClosed signals.
+
+
+
+
+ (as stable API)
+
+ Emitted when a channel is closed and hence disappears from the
+ Channels property.
+
+
+ This is redundant with the Closed
+ signal on the channel itself, but it does provide full change
+ notification for the Channels property.
+
+
+
+
+
+ The channel which has been removed from the Channels property
+
+
+
+
+
+ (as stable API)
+
+ Mapping representing a class of channels that can be requested
+ from a connection manager, can be handled by a user interface,
+ are supported by a contact, etc.
+
+ Classes of channel are identified by the fixed values of
+ a subset of their properties.
+
+ Channel classes SHOULD always include the keys
+ im.telepathy.v1.Channel.ChannelType
+ and
+ im.telepathy.v1.Channel.TargetHandleType .
+
+
+
+
+ A D-Bus interface name, followed by a dot and a D-Bus property name.
+
+
+
+
+
+ The value of the property.
+
+
+
+
+
+ (as stable API)
+
+ Structure representing a class of channels that can be requested,
+ identified by a set of properties that identify that class of
+ channel.
+
+
+ This will often just be the channel type and the handle type,
+ but can include other properties of the channel - for instance,
+ encrypted channels might require properties that
+ unencrypted channels do not, like an encryption key.
+
+
+ In some cases, these classes of channel may overlap, in the sense
+ that one class fixes all the properties that another class does,
+ plus some more properties.
+
+
+ For older clients to still be able to understand how to request
+ channels in the presence of a hypothetical "encryption" interface,
+ we'd need to represent it like this:
+
+
+ - class 1: ChannelType = Text, TargetHandleType = CONTACT
+ - class 2: Channel.ChannelType = Text,
+ Channel.TargetHandleType = CONTACT,
+ Encryption.Encrypted = TRUE
+
+
+
+
+
+
+ The property values that identify this requestable channel class.
+ These properties MUST be included in requests for a channel of this
+ class, and MUST take these values.
+
+ Clients that do not understand the semantics of all the
+ Fixed_Properties MUST NOT request channels of this class, since
+ they would be unable to avoid making an incorrect request.
+
+ This implies that connection managers wishing to make channels
+ available to old or minimal clients SHOULD have a channel class
+ with the minimum number of Fixed_Properties, and MAY additionally
+ have channel classes with extra Fixed_Properties.
+
+ Interface designers SHOULD avoid introducing fixed properties
+ whose types are not serializable in a .manager
+ file.
+
+
+ Connection managers with a fixed property that is not
+ serializable cannot have a complete .manager
+ file.
+
+
+
+
+
+
+ Properties that MAY be set when requesting a channel of this
+ channel type and handle type.
+
+ This array MUST NOT include properties that are in the
+ Fixed_Properties mapping.
+
+ Properties in this array may either be required or optional,
+ according to their documented semantics.
+
+
+ For instance, if
+ TargetHandleType takes a value that is not Handle_Type_None,
+ one or the other of TargetHandle and TargetID is required.
+ Clients are expected to understand the documented relationship
+ between the properties, so we do not have separate arrays
+ of required and optional properties.
+
+
+
+
+
+
+ (as stable API)
+
+ The classes of channel that are expected to be available on this
+ connection, i.e. those for which
+ CreateChannel can reasonably
+ be expected to succeed. User interfaces can use this information
+ to show or hide UI components.
+
+ This property cannot change after the connection has gone to
+ state Connection_Status_Connected, so there is no change
+ notification (if the connection has context-dependent capabilities,
+ it SHOULD advertise support for all classes of channel that it might
+ support during its lifetime). Before this state has been reached,
+ the value of this property is undefined.
+
+
+ This is not on an optional interface, because connection
+ managers can always offer some sort of clue about the channel
+ classes they expect to support (at worst, they can announce
+ support for everything for which they have code).
+
+
+
+
This models a connection to a single user account on a communication
service. Its basic capability is to provide the facility to request and
@@ -747,6 +1280,9 @@ USA.
and signals have been removed from this interface including
anything to do with handle reference counting.
+ The Requests interface
+ is now part of Connection.
+
diff --git a/spec/Connection_Interface_Contact_Capabilities1.xml b/spec/Connection_Interface_Contact_Capabilities1.xml
index 51400cb..6a30c9d 100644
--- a/spec/Connection_Interface_Contact_Capabilities1.xml
+++ b/spec/Connection_Interface_Contact_Capabilities1.xml
@@ -194,7 +194,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
The contact's capabilities. These should be represented
in the same way as in RequestableChannelClasses ,
except that they may have more fixed properties or fewer allowed
properties, to represent contacts who do not have all the
diff --git a/spec/Connection_Interface_Requests.xml b/spec/Connection_Interface_Requests.xml
deleted file mode 100644
index c08860f..0000000
--- a/spec/Connection_Interface_Requests.xml
+++ /dev/null
@@ -1,582 +0,0 @@
-
-
- Copyright (C) 2008 Collabora Limited
- 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.
-
-
-
-
- (as stable API)
-
-
- An enhanced version of the Telepathy connection interface, which can
- represent bundles of channels that should be dispatched together, and
- does not assume any particular properties by which channels are
- uniquely identifiable.
-
-
-
- (as stable API)
-
-
- Enough details of a channel that clients can work out how to dispatch
- or handle it.
-
-
-
-
- The object path of the channel.
-
-
-
-
-
- Properties of the channel.
-
- 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.
-
-
- If properties that could change were included, the following
- race condition would be likely to exist in some cases:
-
-
- - NewChannels or Get("Channels") includes a property P with
- value V1
- - Client creates a proxy object for the channel
- - The value of P changes to V2
- - Client connects to PChanged signal
- - Client should call Get("P") or GetAll here, to avoid the
- race, but client's author has forgotten to do so
- - Proxy object thinks P == V1, but actually P == V2
-
-
- We've taken the opportunity to make the API encourage the
- client author to get it right. Where possible, we intend that
- properties whose value will be used in channel dispatching
- or other "early" processing will be defined so that they are
- immutable (can never change).
-
-
- Each dictionary MUST contain the keys
- im.telepathy.v1.Channel.ChannelType ,
- im.telepathy.v1.Channel.TargetHandleType ,
- im.telepathy.v1.Channel.TargetHandle ,
- im.telepathy.v1.Channel.TargetID
- and
- im.telepathy.v1.Channel.Requested .
-
-
-
- We expect these to be crucial to the channel-dispatching
- process.
-
-
-
-
-
-
- (as stable API)
- It is now guaranteed that
- CreateChannel returns the channel before NewChannels announces it
- (the reverse was previously guaranteed).
-
-
- Request that an entirely new channel is created.
-
-
-
-
- A dictionary containing desirable properties, which MUST include
- ChannelType .
- Some properties
- are defined such that only an exact match makes sense, and
- connection managers MUST NOT satisfy a request with a channel
- where that property does not match; some properties are defined
- such that the connection manager MAY treat the request as merely
- a hint, and make a best-effort attempt to satisfy it. This is
- documented separately for each property.
-
- If this dictionary contains a property whose semantics
- are not known to the connection manager, this method MUST fail
- without side-effects (in particular it must not create a new
- channel).
-
-
- This is necessary if we want to be able to invent properties
- in future that, when used in a request, are hard requirements
- rather than just hints. A connection manager that did not know
- the semantics of those properties could incorrectly return a
- new channel that did not satisfy the requirements.
-
-
- The connection manager MUST NOT respond successfully,
- and SHOULD NOT create a new channel or cause any other
- side-effects, unless it can create a new channel that satisfies
- the client's requirements.
-
- Properties that will be set by this argument need not have write
- access after the channel has been created - indeed, it is
- expected that most will be read-only.
-
-
-
-
-
- The Channel object, which MUST NOT be signalled with
- NewChannels until after this method
- returns.
-
-
- This allows the requester to alter its handling of
- NewChannels by knowing whether one of the channels satisfied
- a request it made.
-
-
-
-
-
-
- Properties of the channel that was produced, equivalent to
- the properties in Channel_Details .
- Connection managers MUST NOT include properties here whose
- values can change, for the same reasons as in
- Channel_Details .
-
-
-
-
-
-
-
-
- The channel request was one that can never succeed,
- such as requesting an unsupported channel type, or requesting
- a channel type which this connection manager does not support with
- the given target handle type.
-
-
-
-
- An invalid handle was requested as the value of a property whose
- value is a handle (like
- Channel.TargetHandle ),
- or a syntactically invalid identifier was requested as the value
- of a property whose value is the string corresponding to a handle
- (like Channel.TargetID ).
-
-
-
-
- The request matched the fixed properties of a
- Requestable_Channel_Class in
- RequestableChannelClasses , but the
- allowed arguments did not make sense; for example, a RoomList1
- was requested, but the Server
- property provided was not a valid DNS name.
-
-
-
-
- The requested channel cannot be created because the requested
- contact is using a client that lacks a particular feature.
-
-
-
-
- The requested channel cannot be created because the target is
- offline.
-
-
-
-
- The requested channel cannot be created, but in
- principle, a similar request might succeed in future.
- For instance, this might be because:
-
-
- - a channel matching the request already exists and the
- protocol requires that only one such channel can exist at a
- time
- - a channel matching the request has already been requested
- (by a previous call to CreateChannel,
-
EnsureChannel ,
- or similar) and the protocol requires that only one such
- channel can exist at a time
-
-
-
-
-
-
-
-
-
-
-
-
- It is now guaranteed that if
- the channel was created by this call to EnsureChannel, it's returned
- before NewChannels announces it (the reverse was previously
- guaranteed).
-
-
- Request that channels are ensured to exist.
-
-
- The connection manager is in the best position to determine which
- existing channels could satisfy which requests.
-
-
-
-
-
-
- A dictionary containing desirable properties, with the same
- semantics as the corresponding parameter to
- CreateChannel .
-
-
-
-
-
- If false, the caller of EnsureChannel MUST assume that some
- other process is handling this channel; if true, the caller of
- EnsureChannel SHOULD handle it themselves or delegate it to another
- client.
-
- If the creation of a channel makes several calls to EnsureChannel
- (and no other requests) successful, exactly one of those calls MUST
- return a true value for this argument.
-
- If the creation of a channel makes other requests successful,
- the value returned for this argument MUST be such that exactly
- one of the clients making requests ends up responsible for the
- channel. In particular, if
- CreateChannel returns a channel
- C, any EnsureChannel calls that also return C
- MUST return a false value for this argument.
-
-
-
-
-
- The Channel object. If it was created as a result of this method
- call, it MUST NOT be signalled by
- NewChannels until after this method
- returns.
-
-
- This allows the requester to alter its handling of
- NewChannels by knowing whether one of the channels satisfied
- a request it made.
-
-
-
-
-
-
- Properties of the channel that was produced, equivalent to
- the properties in Channel_Details .
- Connection managers MUST NOT include properties here whose
- values can change, for the same reasons as in
- Channel_Details .
-
-
-
-
-
-
-
-
- The channel request was one that can never succeed,
- such as requesting an unsupported channel type, or requesting
- a channel type which this connection manager does not support with
- the given target handle type.
-
-
-
-
- An invalid handle was requested as the value of a property whose
- value is a handle (like
- Channel.TargetHandle ),
- or a syntactically invalid identifier was requested as the value
- of a property whose value is the string corresponding to a handle
- (like Channel.TargetID ).
-
-
-
-
- The request matched the fixed properties of a
- Requestable_Channel_Class in
- RequestableChannelClasses , but the
- allowed arguments did not make sense; for example, a RoomList1
- was requested, but the Server
- property provided was not a valid DNS name.
-
-
-
-
- The requested channel cannot be created because the requested
- contact is using a client that lacks a particular feature.
-
-
-
-
- The requested channel cannot be created because the target is
- offline.
-
-
-
-
- The requested channel cannot be created, but in
- principle, a similar request might succeed in future.
-
-
-
-
-
-
-
-
-
-
- (as stable API)
- Added a guarantee of ordering
- relative to the old NewChannel signal (now removed)
- Added recommendation against
- announcing channels together
-
-
- A new channel has been created. The connection manager
- SHOULD emit a single signal for each channel created.
-
- For example, joining a MUC Tube in XMPP requires joining the
- corresponding MUC (chatroom). Either the connection manager
- should announce a new Text channel
- separately, or not expose the Text channel on the bus
- until it's actually requested (or an incoming message
- appears).
-
-
- Signalling the creation of multiple channels together
- makes writing simple clients much more complicated, can
- result in lost messages, and isn't nearly as useful in
- practice as it sounds.
-
-
-
-
-
- The channels and their details.
-
-
-
-
-
- (as stable API)
-
- A list of all the channels which currently exist on this connection.
- Change notification is via the
- NewChannels and
- ChannelClosed signals.
-
-
-
-
- (as stable API)
-
- Emitted when a channel is closed and hence disappears from the
- Channels property.
-
-
- This is redundant with the Closed
- signal on the channel itself, but it does provide full change
- notification for the Channels property.
-
-
-
-
-
- The channel which has been removed from the Channels property
-
-
-
-
-
- (as stable API)
-
- Mapping representing a class of channels that can be requested
- from a connection manager, can be handled by a user interface,
- are supported by a contact, etc.
-
- Classes of channel are identified by the fixed values of
- a subset of their properties.
-
- Channel classes SHOULD always include the keys
- im.telepathy.v1.Channel.ChannelType
- and
- im.telepathy.v1.Channel.TargetHandleType .
-
-
-
-
- A D-Bus interface name, followed by a dot and a D-Bus property name.
-
-
-
-
-
- The value of the property.
-
-
-
-
-
- (as stable API)
-
- Structure representing a class of channels that can be requested,
- identified by a set of properties that identify that class of
- channel.
-
-
- This will often just be the channel type and the handle type,
- but can include other properties of the channel - for instance,
- encrypted channels might require properties that
- unencrypted channels do not, like an encryption key.
-
-
- In some cases, these classes of channel may overlap, in the sense
- that one class fixes all the properties that another class does,
- plus some more properties.
-
-
- For older clients to still be able to understand how to request
- channels in the presence of a hypothetical "encryption" interface,
- we'd need to represent it like this:
-
-
- - class 1: ChannelType = Text, TargetHandleType = CONTACT
- - class 2: Channel.ChannelType = Text,
- Channel.TargetHandleType = CONTACT,
- Encryption.Encrypted = TRUE
-
-
-
-
-
-
- The property values that identify this requestable channel class.
- These properties MUST be included in requests for a channel of this
- class, and MUST take these values.
-
- Clients that do not understand the semantics of all the
- Fixed_Properties MUST NOT request channels of this class, since
- they would be unable to avoid making an incorrect request.
-
- This implies that connection managers wishing to make channels
- available to old or minimal clients SHOULD have a channel class
- with the minimum number of Fixed_Properties, and MAY additionally
- have channel classes with extra Fixed_Properties.
-
- Interface designers SHOULD avoid introducing fixed properties
- whose types are not serializable in a .manager
- file.
-
-
- Connection managers with a fixed property that is not
- serializable cannot have a complete .manager
- file.
-
-
-
-
-
-
- Properties that MAY be set when requesting a channel of this
- channel type and handle type.
-
- This array MUST NOT include properties that are in the
- Fixed_Properties mapping.
-
- Properties in this array may either be required or optional,
- according to their documented semantics.
-
-
- For instance, if
- TargetHandleType takes a value that is not Handle_Type_None,
- one or the other of TargetHandle and TargetID is required.
- Clients are expected to understand the documented relationship
- between the properties, so we do not have separate arrays
- of required and optional properties.
-
-
-
-
-
-
- (as stable API)
-
- The classes of channel that are expected to be available on this
- connection, i.e. those for which
- CreateChannel can reasonably
- be expected to succeed. User interfaces can use this information
- to show or hide UI components.
-
- This property cannot change after the connection has gone to
- state Connection_Status_Connected, so there is no change
- notification (if the connection has context-dependent capabilities,
- it SHOULD advertise support for all classes of channel that it might
- support during its lifetime). Before this state has been reached,
- the value of this property is undefined.
-
-
- This is not on an optional interface, because connection
- managers can always offer some sort of clue about the channel
- classes they expect to support (at worst, they can announce
- support for everything for which they have code).
-
-
-
-
-
-
-
diff --git a/spec/Protocol.xml b/spec/Protocol.xml
index c77f508..0cd0786 100644
--- a/spec/Protocol.xml
+++ b/spec/Protocol.xml
@@ -53,7 +53,7 @@ Interfaces=
[Protocol example]
Interfaces=
-ConnectionInterfaces=im.telepathy.v1.Connection.Interface.Requests;
+ConnectionInterfaces=
param-account=s required
param-password=s required secret
RequestableChannelClasses=text;
@@ -149,7 +149,7 @@ allowed=im.telepathy.v1.Channel.TargetHandle;im.telepathy.v1.Channel.TargetID;
Connection to this protocol (i.e. they will,
or might, appear in the Connection's RequestableChannelClasses property).
Whether a Connection will have all, some or none of these
diff --git a/spec/Protocol_Interface_Addressing1.xml b/spec/Protocol_Interface_Addressing1.xml
index f42770f..2312822 100644
--- a/spec/Protocol_Interface_Addressing1.xml
+++ b/spec/Protocol_Interface_Addressing1.xml
@@ -116,7 +116,7 @@ AddressableURISchemes=tel;sip;
offline. When it is connected the addressable URI schemes should be
retrieved from the
Requests.RequestableChannelClasses 's
+ namespace="im.telepathy.v1.Connection">RequestableChannelClasses's
TargetURIScheme fixed-property instead.
Connection managers with a .manager
file
diff --git a/spec/all.xml b/spec/all.xml
index 3f3ad63..20d15c8 100644
--- a/spec/all.xml
+++ b/spec/all.xml
@@ -49,7 +49,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
--
1.8.4.2