-----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----- _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
