[Telepathy] Requestotron use-cases, part 2 (dispatching, not including Tubes or FT)
Xavier Claessens
xclaesse at gmail.com
Wed Apr 30 03:04:01 PDT 2008
Thanks for writing all use cases! Here is a copy/past of comments I
wrote on IRC:
About the usecase "*dis3: Incoming 1-1 text message with window closed"
1) Empathy closes the channel when the window/tab is closed.
2) In current implementation empathy don't steal focus. steal focus only
happened when MC quit and restart so it forgets about filters.
3) I suggested that the chat UI don't close the channel, but that
depends on the dispatcher. My idea is that the dispatcher could give the
channel to handlers in a priority order and don't dispatch to lower
priority until current priority tells to continue the dispatching. with
that system the chat UI is just a handler like others, and we could have
handlers with lower priority that want the channel after the chat UI is
done with it. So in that case it's MC that is responsible to close the
channel when there is no more lower priority handlers.
Xavier Claessens
Le lundi 28 avril 2008 à 14:56 +0100, Simon McVittie a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Here's a first round of use-cases for the improved RequestChannel API.
> This part only covers incoming things that need dispatching,
> and doesn't cover ad-hoc chatrooms a la MSN, Tubes or file transfers (because
> they're hard and I'll think about them later).
>
> Mardy has sent me some notes about how MC currently behaves, which I'll
> read and incorporate next.
>
> HTML at <http://people.collabora.co.uk/~smcv/dispatch.html>, Darcs branch
> at <http://monkey.collabora.co.uk/tp-spec-smcv-usecases> (it's written
> in reStructuredText), current text later in this email for easy quoting.
>
> Please reply with any comments or extra use cases for dispatching incoming
> channels, that are not the "hard" cases I have already identified (of
> course, if you want to write up the hard cases in the same sort of
> detail, go ahead...)
>
> Regards,
> Simon
>
> Requesting channels
> ===================
>
> .. contents::
>
> Outgoing 1-1 text chat
> - ----------------------
>
> _`req1`: Chat from chat UI
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Romeo has a chat or IM UI open already, and wants to use it to chat to Juliet.
> He selects Juliet from a contact list or types in her username on some IM
> service.
>
> Current implementation::
>
> if a channel with GetHandle() -> (CONTACT, juliet) exists:
> foreground its window or tab
> else:
> RequestChannel (Text, CONTACT, juliet, suppress_handler=TRUE)
>
> _`req2`: Chat from elsewhere
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Juliet wants to talk to Romeo. She chooses his entry in an address book
> or other list of people (not necessarily Telepathy-centric) and is presented
> with a list of possible ways to talk to him. She decides to use text chat.
>
> Current implementation::
>
> address book asks Mission Control for a channel with
> (Text, CONTACT, romeo)
> Mission Control calls RequestChannel (Text, CONTACT, romeo,
> suppress_handler=FALSE) on CM
> Mission Control dispatches the channel to the default/only handler
>
> if the channel is new:
> the channel handler creates a new window or tab
> else:
> the channel handler puts the existing window or tab in the foreground
>
> Problems:
>
> * It's rather bizarre that Mission Control re-dispatches an existing channel
> as though it was new
>
> * It's very bizarre that the channel handler interprets HandleChannel on a
> channel it's already handling as "put it in the foreground". If we mean
> "put this in the foreground" we should say so.
>
> _`req3`: collaborative app
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Romeo is collaborating on a document with Mercutio, and wants to have a chat
> embedded in his AbiWord instance, separate from any other chat with Mercutio
> that may be ongoing.
>
> Current implementation: impossible, even in protocols supporting
> conversation threads, because the spec can't represent them
>
> Outgoing VoIP call
> - ------------------
>
> _`req4`: Call from call UI
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Romeo has a VoIP UI open already, and wants to use it to chat to Juliet.
> He selects Juliet from a contact list or types in her username on some IM
> service.
>
> Theoretical implementation::
>
> if a channel containing handle juliet exists:
> foreground its window or tab
> else:
> RequestChannel (StreamedMedia, NONE, 0, suppress_handler=TRUE)
> RequestStreams (juliet, [AUDIO, VIDEO])
>
> Problems:
>
> * This is what the spec says we should do, but it doesn't actually work yet,
> at least in telepathy-gabble
> <https://bugs.freedesktop.org/show_bug.cgi?id=14602>
> * Finding out whether a channel containing juliet's handle exists is
> needlessly laborious
> * Unless the VoIP UI keeps a table of (handle => channel) (which can't
> necessarily be done - some protocols allow "parallel" calls), the following
> race condition::
>
> choose to call Juliet
> RequestChannel (StreamedMedia, NONE, 0, suppress_handler=TRUE) (request A)
> choose to call Juliet
> RequestChannel (StreamedMedia, NONE, 0, suppress_handler=TRUE) (request B)
> Request A returns /.../ChannelA
> Request B returns /.../ChannelB
>
> can result in unnecessarily opening two parallel calls to the same contact
>
> Practical implementation::
>
> if a channel containing handle juliet exists:
> foreground its window or tab
> else:
> RequestChannel (StreamedMedia, NONE, 0, suppress_handler=TRUE)
> AddMembers ([juliet])
> RequestStreams (juliet, [AUDIO, VIDEO])
>
> Problems:
>
> * Same needlessly laborious processing as in the theoretical implementation
> * Same race condition as in the theoretical implementation
> * Juliet appears in the remote-pending set before any attempt has really
> been made to call her, which is misleading
>
> Deprecated implementation::
>
> if a channel containing handle juliet exists:
> foreground its window or tab
> else:
> RequestChannel (StreamedMedia, CONTACT, juliet, suppress_handler=TRUE)
> RequestStreams (juliet, [AUDIO, VIDEO])
>
> Problems:
>
> * All the problems of the practical implementation
> * Implementors might be misled into thinking that the semantics resemble
> text channels more closely than they really do
>
> _`req5`: Call from elsewhere
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Juliet wants to talk to Romeo. She chooses his entry in an address book
> or other list of people (not necessarily Telepathy-centric) and is presented
> with a list of possible ways to talk to him. She decides to use a VoIP call.
>
> Current implementation::
>
> RequestChannel (StreamedMedia, NONE, 0, suppress_handler=FALSE)
> perhaps AddMembers ([romeo])
> RequestStreams (romeo, [AUDIO, VIDEO])
>
> The channel handler creates a new window or tab for the new channel
>
> Problems:
>
> * The requester has to keep interacting with the channel, it's not
> "fire and forget"
> * Creates a new channel, which is unlikely to be what Juliet wanted
>
> Deprecated (?) implementation::
>
> ask Mission Control for a channel (StreamedMedia, CONTACT, romeo)
> Mission Control does... something?
>
> Problems:
>
> * Mission Control doesn't know whether to use an existing channel to Romeo,
> or create a new one (using an existing channel is *probably* right)
> * Looking for channels to talk to Romeo is hard (have to interact with lots of
> group interfaces)
>
> _`req6`: collaborative app
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Romeo is collaborating on a document with Mercutio, and wants to have a chat
> embedded in his AbiWord instance, separate from any other chat with Mercutio
> that may be ongoing.
>
> Current implementation: same as req5_
>
> Problems: same as req5_
>
> Joining a named chatroom by request
> - -----------------------------------
>
> _`req7`: joining chatroom from chatroom UI
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Tybalt starts an IRC-style chatroom client and wants to join a chatroom, either
> by explicit request or because his client auto-joins his favourite rooms.
>
> Current implementation::
>
> if a channel with GetHandle() -> (ROOM, chatroom_handle) exists:
> foreground its window or tab
> else:
> RequestChannel (Text, ROOM, chatroom_handle, suppress_handler=TRUE)
>
> Problems:
>
> * Tybalt doesn't get a chance to choose his nickname before joining
>
> _`req8`: joining chatroom from elsewhere
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Benvolio chooses to rejoin a recently-used chatroom from (hypothetical
> functionality of) the GNOME Places menu.
>
> Current implementation::
>
> GNOME menu asks Mission Control for a channel with
> (Text, ROOM, chatroom_handle)
> Mission Control calls RequestChannel (Text, ROOM, chatroom_handle,
> suppress_handler=FALSE) on CM
> Mission Control dispatches the channel to the default/only handler
>
> if the channel is new:
> the channel handler creates a new window or tab
> else:
> the channel handler puts the existing window or tab in the foreground
>
> Problems:
>
> * As for req7_, Benvolio doesn't get a chance to choose his nickname before
> joining
>
> * As for req2_, it's rather bizarre that Mission Control re-dispatches an
> existing channel as though it was new
>
> * As for req2_, it's very bizarre that the channel handler interprets
> HandleChannel on a channel it's already handling as "put it in the
> foreground"
>
> Listing named chatrooms
> - -----------------------
>
> _`req9`: listing chatrooms on "home" server
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Romeo wants to list all the chatrooms on the server or service that hosts his
> account.
>
> Current implementation::
>
> RequestChannel (RoomList, NONE, 0, suppress_handler=TRUE)
>
> Notes:
>
> * There doesn't seem to be any use case for suppress_handler=FALSE here,
> since a default handler for chatroom lists doesn't really make sense
>
> Problems:
>
> * Gabble implements this badly, by treating the room list as a singleton
>
> * Some protocols (IRC!) are terrible, and on these, the room list actually
> *is* a singleton
>
> _`req10`: listing chatrooms on "foreign" server
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Romeo wants to list all the chatrooms on the server that hosts Juliet's
> account.
>
> Current implementation: impossible
>
> Contact lists
> - -------------
>
> _`req11`: typical contact list UI
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Current best-practice to get contact lists (should not use ListChannels
> and NewChannel, cf my conversation with Zdra in #telepathy on 2008-04-25)::
>
> RequestChannel (ContactList, CONTACT_LIST, handle("subscribe"))
> RequestChannel (ContactList, CONTACT_LIST, handle("publish"))
> RequestChannel (ContactList, CONTACT_LIST, handle("hide"))
> RequestChannel (ContactList, CONTACT_LIST, handle("allow"))
> RequestChannel (ContactList, CONTACT_LIST, handle("deny"))
>
> Current best-practice to get initial user-defined groups::
>
> ListChannels ()
>
> (finding new groups will be part of the "incoming" use cases list)
>
> Problems:
>
> * Slightly unclear whether suppress_handler should be TRUE or FALSE -
> depends on "incoming" use cases
>
> _`req12`: creating a user-defined contact group
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Current implementation::
>
> RequestChannel (ContactList, GROUP, handle("Colleagues"),
> suppress_handler=FALSE)
>
> Ad-hoc chatrooms
> - ----------------
>
> FIXME: there are quite a few cases here.
>
> File transfers
> - --------------
>
> FIXME: ... are hard
>
> Tubes
> - -----
>
> FIXME: ... are hard (see also, OLPC's Activity model)
>
> ..
> vim:set sw=4 sts=4 et:
> -----BEGIN PGP SIGNATURE-----
>
> iD8DBQFIFdeaWSc8zVUw7HYRAljYAKDuxUx8fAbobr/uQ/BtA9lBeQMvygCfaMU5
> Vs7PrjWpYtt3aarbhRzoDo4=
> =Ved+
> -----END PGP SIGNATURE-----
> _______________________________________________
> Telepathy mailing list
> Telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
More information about the Telepathy
mailing list