[Telepathy] Requestotron use-cases, part 7 (starting to propose implementations)
Simon McVittie
simon.mcvittie at collabora.co.uk
Thu Jun 5 07:25:49 PDT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here are some implementation proposals, corresponding to
those currently in <http://people.collabora.co.uk/~smcv/dispatch.html>
and <http://people.collabora.co.uk/~smcv/request.html>. I'll be adding
to these, but I wanted to get a snapshot of how we're currently thinking into
telepathy-spec 0.17.7 (due out today or tomorrow).
My current sketches of the future API can be found at
<http://monkey.collabora.co.uk/tp-spec-smcv-requests/> - I've put a HTMLized
version in <http://people.collabora.co.uk/~smcv/cd.html> which is
occasionally updated. This is all subject to quite a lot of change over
the next few weeks as we argue about the design...
Diffs below for easier quoting and commentary.
Regards,
Simon
diff -rN -u -p old-tmpYAxNhL/doc/dispatch.txt new-tmpYAxNhL/doc/dispatch.txt
- --- old-tmpYAxNhL/doc/dispatch.txt 2008-06-05 14:55:09.015495211 +0100
+++ new-tmpYAxNhL/doc/dispatch.txt 2008-06-05 14:55:09.051497461 +0100
@@ -76,6 +76,14 @@ Problems with this alternative implement
executes the real handler as a subprocess, via exec(2) or via dlopen(3) if
needed
+Proposed implementation:
+
+* The logger is an Client and a Client.Observer
+
+* The tray icon is a Client and a Client.Approver
+
+* The chat UI is a Client and a Client.ChannelHandler
+
_`dis2`: Incoming 1-1 text message
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -94,6 +102,20 @@ Problems:
mechanism for the new-channel case (this would be fixed by dis1impl2_)
(call this _`dis2problem2`)
+Alternative implementation, _`dis2impl2`:
+
+* When a ChannelHandler that was handling a channel closes, the channel
+ dispatcher forcibly closes that channel
+
+Problems:
+
+* Incoming messages might be lost (there is a race)
+
+Alternative implementation, _`dis2impl3`:
+
+* When a ChannelHandler that was handling a channel closes, the channel
+ dispatcher re-dispatches that channel (to the same or a different handler)
+
_`dis3`: Incoming 1-1 text message with window closed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -152,17 +174,82 @@ Current implementation: impossible on pr
just a special case of ad-hoc chatrooms, since we guarantee uniqueness
per (handle type, handle, channel type) for all handle types except NONE
+Proposed implementation:
+
+* The new thread is announced as a separate ChannelBundle (channels in each
+ bundle have a ThreadID property)
+
+* The new thread is dispatched to observers, approvers and the handler
+ separately
+
_`dis5`: Incoming 1-1 text chat thread related to a VoIP call
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Juliet is talking to Romeo over VoIP; there is no text channel open between
- -them. Romeo sends Juliet a text chat message (e.g. to send her a URI
- -instead of having to spell it out verbally), which should appear in the same
- -UI as the VoIP call.
+them. Romeo sends Juliet a text chat message (e.g. to send her a URI instead of
+having to spell it out verbally), which should appear in the same
+UI as the VoIP call if possible.
Current implementation: impossible, we have no representation for related
channels
+Sub-cases exist, some of which are more problematic:
+
+_`dis5a`: Juliet's VoIP UI also supports Text
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Proposed implementation:
+
+* The new Text channel is announced with the same bundle ID as the old
+ VoIP channel; observers are invoked
+
+* The channel dispatcher notices that Juliet's UI (which is the
+ handler for this bundle) supports Text channels, and tells it to handle
+ the new Text channel too. Approvers are not invoked
+
+_`dis5b`: Juliet's VoIP UI does not support Text
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Proposed implementation:
+
+* The new Text channel is announced with the same bundle ID as the old
+ VoIP channel; observers are invoked
+
+* The channel dispatcher notices that Juliet's UI (which is the
+ handler for this bundle) does not support Text channels, and falls back
+ to splitting the channel bundle: the new channel goes to approvers and to
+ a channel handler
+
+_`dis5c`: "the same UI" is not unique
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Suppose Juliet has two channel handlers:
+
+* Empathy: supports text and VoIP, currently in use for VoIP
+* TChat: supports text and file transfers
+
+Suppose that Romeo sends Juliet a file transfer offer, then a Text message.
+Juliet's channel dispatcher sees the following:
+
+* initially, there is a VoIP channel C1 in a bundle B, handled by Empathy
+* next, there is a FT channel C2 in a bundle B. Empathy cannot handle it,
+ so according to `dis5b`_, only TChat is offered to approvers.
+ Juliet accepts the file transfer and it is handled by TChat
+* now the Text channel, C3, appears. What happens to it? Is it handled by
+ Empathy or by TChat without running approvers, or are they both offered to
+ approvers?
+
+_`dis5d`: not a channel handler
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Suppose that Juliet's UI got the channel via use-case req1_. No approver
+or handler was ever invoked, so how does Juliet's channel dispatcher
+know that that UI should get subsequent channels?
+
+(The same issue exists in the proposed API if an approver calls Claim().)
+
+.. _req1: request.html#req1
+
_`dis6`: Incoming 1-1 text chat thread related to a collaborative app
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -173,6 +260,8 @@ comments, which should appear in a chat
Current implementation: impossible, we have no representation for related
channels
+Proposed implementation: the same as dis5_, with the same problems
+
Invitations to named chatrooms
------------------------------
@@ -236,6 +325,12 @@ Problems:
* The Group interface is unnecessarily complex just to find out who's calling
+Proposed implementation:
+
+* The channel has properties ...Channel.InitiatorHandle,
+ ...Channel.InitiatorID which indicate Juliet's handle and ID
+ (JID, SIP URI, etc.) immediately
+
_`dis9`: Missed incoming VoIP call
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -249,6 +344,12 @@ Problems:
* Information can be lost, depending on timing
(https://bugs.freedesktop.org/show_bug.cgi?id=14606)
+Proposed implementation:
+
+* The channel has properties ...Channel.InitiatorHandle,
+ ...Channel.InitiatorID which indicate Juliet's handle and ID
+ (JID, SIP URI, etc.) immediately
+
_`dis10`: Incoming VoIP call related to some other channel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -260,6 +361,8 @@ Current implementation: the call is indi
Problems: Juliet can't get the UI she wants
+Proposed implementation: the reverse of dis5_, with the same issues
+
Contact lists
-------------
@@ -284,9 +387,16 @@ Problems:
process with a contact-list UI might be interested in them - or not, since
best practice is to request the contact lists that you want to use
- -Best-practice solution: clients SHOULD NOT be channel handlers for contact
- -lists; clients SHOULD explicitly request any contact list channels that they
- -want to use
+* On Maemo devices, the address-book synchronization process is currently
+ a handler for contact lists - this excludes the possibility of a third-party
+ process that does the same thing
+
+Best-practice solution:
+
+* Clients SHOULD NOT be channel handlers for contact lists; clients SHOULD
+ explicitly request any contact list channels that they want to use
+
+* Perhaps clients interested in contact lists should be observers instead?
_`dis12`: A user-defined contact group is found during login
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -391,6 +501,8 @@ functionality, the text or VoIP UI shoul
the channel dispatcher should fall back to launching a standalone file
transfer handler.
+Proposed implementation and problems: same as dis5_
+
_`dis19`: Receiving a file unexpectedly
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -398,6 +510,8 @@ Juliet is not interacting with Romeo whe
appropriate UI needs to be launched to indicate that the file has been
offered.
+Proposed implementation: same as dis1_
+
_`dis20`: Receiving a file in a collaborative application
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -406,6 +520,12 @@ to use to transfer snapshots of state, o
(e.g. in a word processor, you could receive an inline image that is
embedded in the document).
+Proposed implementation: same as dis6_
+
+Additional problems: if the file transfer is part of the word processor's
+IPC mechanism, then it *really* wants to get the file transfer, rather than
+having another process get it as a result of a situation like dis5c_
+
Tubes
-----
@@ -436,6 +556,18 @@ Problems:
.. _Clique: http://telepathy.freedesktop.org/xmpp/clique.html
+Proposed implementation:
+
+* Each Tube is its own channel
+
+* OLPC Activities map 1:1 to conversation threads
+
+* For compatibility with older OLPC code, we place each activity thread
+ in a new chatroom
+
+* For compatibility with older OLPC code, the Tubes channel type still exists
+ in a deprecated state
+
_`dis22`: Invited to be a client in an existing UDP/TCP client/server protocol
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -449,6 +581,10 @@ her a VNC connection to his computer so
Romeo offers Mercutio and Benvolio access to an OpenArena server running
on his local computer.
+Proposed implementation:
+
+* Each TCP/UDP Tube is its own channel, with a thread ID associated with it
+
Failures and other exceptional cases
------------------------------------
@@ -464,6 +600,9 @@ on the client side.
Current implementation: a filter in Mission Control 4.x
+Proposed implementation: a filter (dlopen()ed or hard-coded) in Mission
+Control 5.x - we do not propose to allow this sort of thing over D-Bus
+
Miscellaneous
-------------
@@ -482,6 +621,20 @@ Problems:
source of notifications doesn't really scale. Can't we solve this at the
level of the fd.o Desktop Notification spec instead?
+Proposed implementation:
+
+* any application that really wants to know about Telepathy channels can be
+ an Approver
+
+_`dis29`: multiple notification mechanisms (2)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A Telepathy gnome-panel applet needs to be able to indicate incoming calls or
+channels. The Empathy contact list window should also be able to indicate
+incoming calls or channels, e.g. by highlighting the contact.
+
+Proposed implementation: they're both Approvers
+
_`dis25`: brightness on portable devices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -494,6 +647,9 @@ Current implementation: a filter in Miss
Problems: is this really just a special case of dis24_?
+Proposed implementation: either a filter in Mission Control 5.x, or the
+device-state service (which handles the backlight) can be made an Observer
+
_`dis26`: multiple channel handers available - 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -507,6 +663,11 @@ Problems:
* There is no way currently to choose between channel handlers, Mission Control
4.x only accepts one chandler.
+Proposed implementation:
+
+* Approvers can select which one to use from among several possible channel
+ handlers
+
_`dis27`: multiple channel handers available - 2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -522,5 +683,11 @@ Problems:
status icon will blink and Romeo won't see it because elisa is running
fullscreen.
+Proposed implementation:
+
+* elisa is an Approver which claims incoming channels using Claim(). The
+ Empathy status icon blinks momentarily, but this is not visible, and because
+ there is no user action, Empathy never approves anything
+
..
vim:set sw=4 sts=4 et:
diff -rN -u -p old-tmpYAxNhL/doc/request.txt new-tmpYAxNhL/doc/request.txt
- --- old-tmpYAxNhL/doc/request.txt 2008-06-05 14:55:09.027495961 +0100
+++ new-tmpYAxNhL/doc/request.txt 2008-06-05 14:55:09.051497461 +0100
@@ -20,6 +20,30 @@ Current implementation::
else:
RequestChannel (Text, CONTACT, juliet, suppress_handler=TRUE)
+Proposed implementation::
+
+ client calls some unspecified method on ChannelDispatcher (FIXME)
+
+ ChannelDispatcher calls RequestChannels (
+ SUPRESS_HANDLER | PREFER_REUSE,
+ [
+ {'...ChannelType': '...Text',
+ '...TargetHandleType': CONTACT,
+ '...TargetHandle': juliet
+ }
+ ])
+
+ if the channel that is returned has the EXISTING flag:
+ ChannelDispatcher returns it to the UI
+ UI foregrounds its window or tab
+ else:
+ channel observers run
+ ChannelDispatcher returns it to the UI
+ UI makes a new window or tab for it
+
+ channel approvers do not run
+ channel handler does not run
+
_`req2`: Chat from elsewhere
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -49,6 +73,30 @@ Problems:
channel it's already handling as "put it in the foreground". If we mean
"put this in the foreground" we should say so.
+Proposed implementation::
+
+ client calls some unspecified method on ChannelDispatcher (FIXME)
+
+ ChannelDispatcher calls RequestChannels (PREFER_REUSE,
+ [
+ {'...ChannelType': '...Text',
+ '...TargetHandleType': CONTACT,
+ '...TargetHandle': juliet
+ }
+ ])
+
+ if the channel that is returned has the EXISTING flag:
+ ChannelDispatcher returns it to the address book, which does nothing
+ much with it
+ FIXME: how do we tell the UI to foreground it?
+ channel observers/approvers/handler do not run
+ else:
+ channel observers run
+ ChannelDispatcher returns it to the address book, which does nothing
+ much with it
+ FIXME: channel approvers probably do not run?
+ FIXME: how do we choose which channel handler should take it?
+
_`req3`: collaborative app
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -59,6 +107,31 @@ that may be ongoing.
Current implementation: impossible, even in protocols supporting
conversation threads, because the spec can't represent them
+Proposed implementation::
+
+ bundle_id = ...Bundle property of AbiWord Tube channel
+
+ client calls some unspecified method on ChannelDispatcher (FIXME)
+
+ ChannelDispatcher calls RequestChannels (PREFER_REUSE | SUPPRESS_HANDLER,
+ [
+ {'...ChannelType': '...Text',
+ '...TargetHandleType': CONTACT,
+ '...TargetHandle': mercutio,
+ '...Bundle': bundle_id,
+ }
+ ])
+
+ channel observers run if the channel did not already exist
+ channel approvers/handler do not run
+ ChannelDispatcher returns channel to AbiWord
+
+ if channel has the requested bundle ID:
+ AbiWord uses it
+ else:
+ AbiWord ignores it (on the basis that someone else is already using
+ it)? FIXME: is this always true?
+
_`req26`: Recovering from disconnection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -82,8 +155,25 @@ Problems:
* the two conversations are unrelated (Juliet cannot distinguish
between this case and req1_)
- -Sketch of a proposed solution: give both conversations a thread UUID, and
- -let the UI provide the same thread UUID when reconnecting
+Proposed implementation (with a new Chan.I.Thread)::
+
+ Romeo's chat UI (or incoming message database) automatically saves the
+ ...Channel.Interface.Thread.ThreadID property of the old channel
+
+ Disconnect/reconnect occurs
+
+ Client calls some unspecified method on ChannelDispatcher (FIXME)
+
+ ChannelDispatcher calls RequestChannels (SUPRESS_HANDLER,
+ [
+ {'...Channel.ChannelType': '...Text',
+ '...Channel.TargetHandleType': CONTACT,
+ '...Channel.TargetHandle': juliet,
+ '...Channel.Interface.Thread.ThreadID': thread_id,
+ }
+ ])
+
+ from here onwards, same as req1
_`req27`: Resuming a conversation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -92,13 +182,13 @@ Romeo chooses a past conversation with J
to resume it. (The definition of threading in XMPP expects that this is
possible.)
- -This is basically req26_ but for a different reason; I expect that the
- -solution can be similar.
- -
Current implementation: same as req2_
Problems: Juliet cannot distinguish between this case and req2_
+Proposed implementation: same as req26_, except that it resembles
+req2_ instead of req1_ (i.e. no SUPRESS_HANDLER flag)
+
_`req28`: Recovering from other's disconnection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -118,6 +208,8 @@ she cannot send messages. When Romeo rec
uniqueness, Juliet's client continues to use the same channel and there
is no disconnection.
+Proposed implementation: Juliet's client continues to use the same channel
+
Outgoing VoIP call
------------------
@@ -297,6 +389,15 @@ Problems:
* Tybalt doesn't get a chance to choose his nickname before joining
+Proposed implementation: some new interface for this functionality is
+created, like Chan.I.Chatroom. RequestChannels arguments contain::
+
+ {'...Channel.ChannelType': '...Channel.Type.Text',
+ '...Channel.TargetHandleType': ROOM,
+ '...Channel.TargetHandle': chatroom_handle,
+ '...Channel.Interface.Chatroom.Nickname': 'the Prince of Cats',
+ }
+
_`req8`: joining chatroom from elsewhere
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -353,6 +454,8 @@ Problems:
* Some protocols (IRC!) are terrible, and on these, the room list actually
*is* a singleton
+Proposed implementation: a straightforward port of the current API
+
_`req10`: listing chatrooms on "foreign" server
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -361,6 +464,9 @@ account.
Current implementation: impossible
+Proposed implementation: in the request, set the Channel.Type.RoomList.Server
+property to the desired DNS name
+
Contact lists
-------------
@@ -433,6 +539,11 @@ Problems:
* Determining whether we already have a channel to Juliet becomes harder
than in req1_
+Proposed implementation:
+
+* Rethink our opinion of how MSN should work, and require butterfly to
+ behave as if true 1-1 channels existed; then this reduces to req1_
+
_`req31`: Recovering from disconnection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -462,6 +573,11 @@ Problems:
* the interaction with offline messages is quite scary
+Proposed implementation:
+
+* Rethink our opinion of how MSN should work, and require butterfly to
+ behave as if true 1-1 channels existed; then this reduces to req26_
+
_`req32`: Resuming a conversation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -476,6 +592,11 @@ Current implementation: same as req13_
Problems: Juliet cannot distinguish between this case and req13_
+Proposed implementation:
+
+* Rethink our opinion of how MSN should work, and require butterfly to
+ behave as if true 1-1 channels existed; then this reduces to req27_
+
_`req33`: Recovering from other's disconnection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -498,6 +619,11 @@ Problems:
conversations with the same members (if this is even allowed by the
protocol)
+Proposed implementation:
+
+* Rethink our opinion of how MSN should work, and require butterfly to
+ behave as if true 1-1 channels existed; then this reduces to req28_
+
_`req14`: Ad-hoc chatroom from chat UI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -545,6 +671,16 @@ Problems:
* The UI can't know that the user would prefer an ad-hoc chatroom, so in
practice it would always have to do this
+Proposed implementation:
+
+* Rethink our opinion of how MSN should work, and require butterfly to
+ behave as if true 1-1 channels existed
+
+* Create a 1-1 channel for the conversation with Mercutio
+
+* Upgrade it to a chatroom by some as-yet unspecified API (FIXME) which would
+ create an ad-hoc chatroom in the same bundle
+
_`req16`: Chat from address book (MSN)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -581,6 +717,13 @@ Problems:
* If both 1-1 and ad-hoc-chatroom channels are available, this would provide
a true 1-1 channel - what if an ad-hoc chatroom was preferred?
+Proposed implementation:
+
+* Rethink our opinion of how MSN should work, and require butterfly to
+ behave as if true 1-1 channels existed
+
+* Create a 1-1 channel for the conversation with Romeo, the same as req2_
+
_`req17`: Ad-hoc chatroom from address book
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -607,6 +750,16 @@ Problems:
* Do protocols like MSN allow us to have two channels with the same members?
+Proposed implementation:
+
+* Rethink our opinion of how MSN should work, and require butterfly to
+ behave as if true 1-1 channels existed
+
+* Create a 1-1 channel for the conversation with Mercutio
+
+* Upgrade it to a chatroom by some as-yet unspecified API (FIXME) which would
+ create an ad-hoc chatroom in the same bundle
+
_`req18`: Ad-hoc chatroom embedded in collaboraborative app
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -625,6 +778,8 @@ Problems:
* Are we allowed to have two MSN switchboards with the same two members?
+Proposed implementation: same as req3_
+
_`req19`: Upgrading a 1-1 chat to a named or ad-hoc chatroom
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -633,12 +788,8 @@ by using thread IDs.
Current implementation: can't be done
- -Hypothetical implementation: smcv has some ideas involving thread UUIDs.
- -
- -Perhaps the various ad-hoc-chatroom cases would become simpler if we
- -"upgraded" from a 1-1 chat to an ad-hoc chatroom when necessary (with this
- -just being a Telepathy API fiction rather than an operation on the
- -server)?
+Hypothetical implementation: request a chatroom channel with the same thread
+ID and bundle ID as the 1-1 chat
File transfers
--------------
@@ -655,6 +806,28 @@ _`req21`: Sending a file from a file man
Romeo right-clicks on a file in his file manager, chooses a "Send to User"
option and chooses to send it to Juliet.
+Proposed implementation::
+
+ client calls some unspecified method on ChannelDispatcher (FIXME)
+
+ ChannelDispatcher calls RequestChannels (
+ 0,
+ [
+ {'...Channel.ChannelType': '...Channel.Type.FileTransfer',
+ '...Channel.TargetHandleType': CONTACT,
+ '...Channel.TargetHandle': juliet,
+ # exact attributes of file offers undecided, but might include:
+ '...Channel.Type.FileTransfer.ContentType': 'image/png',
+ ...
+ }
+ ])
+
+ channel observers run
+ ChannelDispatcher returns it to the address book, which does nothing
+ much with it
+ FIXME: channel approvers probably do not run?
+ FIXME: how do we choose which channel handler should take it?
+
_`req22`: Sending a file automatically in a collaborative application
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -662,6 +835,31 @@ While collaborating on a document with M
image into the document. The collaborative application could usefully choose
to represent this by a file transfer.
+Proposed implementation::
+
+ bundle_id = ...Bundle property of AbiWord Tube channel
+
+ client calls some unspecified method on ChannelDispatcher (FIXME)
+
+ ChannelDispatcher calls RequestChannels (PREFER_REUSE | SUPPRESS_HANDLER,
+ [
+ {'...ChannelType': '...FileTransfer',
+ '...TargetHandleType': CONTACT,
+ '...TargetHandle': mercutio,
+ '...Bundle': bundle_id,
+ ...
+ }
+ ])
+
+ channel observers run if the channel did not already exist
+ channel approvers/handler do not run
+ ChannelDispatcher returns channel to AbiWord
+
+ if channel has the requested bundle ID:
+ AbiWord uses it
+ else:
+ ??? FIXME
+
Tubes
-----
@@ -692,18 +890,30 @@ Problems:
.. _Clique: http://telepathy.freedesktop.org/xmpp/clique.html
+Proposed implementation:
+
+* Associate each Activity with a ChannelBundle using XMPP threading
+
_`req24`: Existing UDP/TCP client/server protocol, serving one client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tybalt asks Juliet to help him fix a problem with his computer. He offers
her a VNC connection to his computer so she can interact with his desktop.
+Proposed implementation:
+
+* The TCP tube is a channel; much like req1_ or req2_
+
_`req25`: Existing UDP/TCP client/server protocol, serving many clients
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Romeo offers Mercutio and Benvolio access to an OpenArena server running
on his local computer.
+Proposed implementation:
+
+* The UDP tube is a channel; much like req1_ or req2_
+
Failures and other exceptional cases
------------------------------------
@@ -720,6 +930,8 @@ Current implementation::
SendError (and soon DeliveryReporting) report the failure
the channel remains open
+Proposed implementation: keep the current implementation
+
_`req35`: failing to make a call
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -731,6 +943,8 @@ Current implementation::
Juliet is removed from the Group interface, with an error for the reason
the StreamedMedia channel closes
+Proposed implementation: keep the current implementation?
+
_`req36`: Cancelling outgoing call
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
iD8DBQFIR/dlWSc8zVUw7HYRAsLeAKCaPM+IEwaPyvR9oLVSajyCDHTeegCdFOtc
xLac8iOak2YQtRssLgkjRxY=
=o57t
-----END PGP SIGNATURE-----
More information about the Telepathy
mailing list