1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
Use cases for connection manager capabilities
=============================================
.. contents::
Connection manager capabilities indicate what sorts of channel a connection
manager could conceivably satisfy a request for. This is closely related to
`channel requesting`_, and can be used by clients to decide what UI to
present.
.. _channel requesting: request.html
For instance, Empathy's Chat -> New Conversation menu can use this mechanism
to decide what connection managers could conceivably have what features.
Fundamentally, it is a Connection that has or lacks a particular feature.
However, it would be useful for some part of Mission Control (account manager?
channel dispatcher?) to cache "expected" capabilities for unconnected
accounts, or perhaps even be able to guess what capabilities an account will
have before it has ever become connected.
The current proposal is:
* "Classes" of requestable channel are identified by (ChannelType,
TargetHandleType) pairs
* If TargetHandleType is not NONE then either TargetHandle or TargetID is
always mandatory, and TargetHandle (if given) is nonzero
* If TargetHandleType is NONE then TargetHandle and TargetID are forbidden
* Other parameters can exist, and can be mandatory or optional; clients MUST
NOT send parameters that aren't explicitly allowed
Problems with this proposal:
* How do we say that not all "valid" values for a parameter are allowed?
For instance we might only support a couple of MIME types for file transfer
* Tentative resolution: we don't, but the request will fail without
side-effects
* Can there potentially be more than one "class" per pair? Representing this
in a UI is likely to be hard
* Tentative resolution: yes, but we'll try to avoid it?
* Would it be useful to indicate what interfaces will/might be supported
by channels of a given class?
Optional parameters which could hypothetically apply to all channels
--------------------------------------------------------------------
* ...Channel.Bundle
* ...Channel.Interface.Thread.ThreadID
* ...Channel.Interface.TLS.Secure
1-1 text chat
-------------
:ChannelType:
...Channel.Type.Text
:TargetHandleType:
CONTACT
:Mandatory parameters other than TargetHandle:
none
:Optional parameters not already mentioned:
none
Chatroom
--------
:ChannelType:
...Channel.Type.Text
:TargetHandleType:
ROOM
:Mandatory parameters other than TargetHandle:
none
:Optional parameters not already mentioned:
...Ch.I.Chatroom.Nickname
1-1 VoIP
--------
:ChannelType:
...Channel.Type.StreamedMedia
:TargetHandleType:
NONE (or CONTACT)
:Mandatory parameters other than TargetHandle:
none
:Optional parameters not already mentioned:
none
Mingle
------
:ChannelType:
...Channel.Type.StreamedMedia
:TargetHandleType:
ROOM
:Mandatory parameters other than TargetHandle:
none
:Optional parameters not already mentioned:
none
RoomList
--------
:ChannelType:
...Channel.Type.Text
:TargetHandleType:
NONE
:Mandatory parameters:
none
:Optional parameters not already mentioned:
none
FileTransfer
------------
:ChannelType:
...Channel.Type.FileTransfer
:TargetHandleType:
CONTACT
:Mandatory parameters other than TargetHandle:
Varies per connection manager!
* SuggestedFilename: mandatory in XMPP XEP-0096 and probably others
* maybe we should make this always mandatory?
* Size: mandatory in XMPP XEP-0096
* we plan to make this always mandatory in requests, for reliable
detection of truncated transfers
* other protocols?
:Optional parameters not already mentioned:
* RandomAccess=True? (XEP-0096 byte ranges)
* Description (XEP-0096)
* ContentType? (can always avoid making this mandatory by defaulting to
'application/octet-stream')
* ContentMD5
* app-defined metadata? (not possible in all, or possibly any, protocols)
D-Bus, Stream, Packet Tube
--------------------------
Attempt 1
~~~~~~~~~
:ChannelType:
...Channel.Type.DBusTube, Ch.T.StreamTube, Ch.T.PacketTube?
(with ...Channel.Interface.Tube)
:TargetHandleType:
CONTACT or ROOM
:Mandatory parameters other than TargetHandle:
Service
AvailableSocketTypes (the request fails if the channel's available
(socket, access control type) pairs have empty intersection with
these)
:Optional parameters not already mentioned:
TubeParameters (omitted and empty a{sv} are interchangeable)
Attempt 2
~~~~~~~~~
:ChannelType:
e.g. ...Channel.Type.DBusTube.com.abisource.AbiCollab,
...Channel.Type.StreamTube.vnc, ...Channel.Type.PacketTube.openarena
(with ...Channel.Interface.Tube and possibly also
...Channel.Interface.DBusTube etc.)
:TargetHandleType:
CONTACT or ROOM
:Mandatory parameters other than TargetHandle:
AvailableSocketTypes as in attempt 1
:Optional parameters not already mentioned:
as in attempt 1
..
vim:set sw=4 sts=4 et:
|
