-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are some of the more complicated use-cases for dispatching incoming channels.
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. Regards, Simon _`dis14`: Forcibly joining a chatroom ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Benvolio connects to an irssi-proxy or other IRC bouncer running on some colo box somewhere. The proxy informs his client that he is already in #telepathy and #farsight. Current implementation: same as dis7_, but Benvolio is already in the members set for those channels Invitations to ad-hoc chatrooms - ------------------------------- _`dis15`: Invitation to an ad-hoc chatroom with one user ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Juliet receives a message from Romeo using MSN, in which "1-1" conversations are actually ad-hoc chatrooms with exactly two members. She would like this to be indistinguishable from Romeo sending her a message over XMPP, in which 1-1 conversations are really 1-1. Current implementation:: NewChannel (Text, NONE, 0, suppress_handler=FALSE) The channel is passed through filters, etc. Problems: * Same as dis8_ and dis1_ combined * It's unclear whether Juliet should be in member or local-pending state in the new channel _`dis16`: Invitation to an ad-hoc chatroom with multiple users ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Romeo receives an invitation to join an ad-hoc chatroom currently containing Mercutio and Benvolio. Current implementation:: NewChannel (Text, NONE, 0, suppress_handler=FALSE) The channel is passed through filters, etc. Problems: * Same as dis15_, but the desired state (member vs local pending) might be different _`dis17`: Upgrading a 1-1 chat to a named or ad-hoc chatroom ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mercutio is talking to Benvolio in a 1-1 chat. Benvolio upgrades the chat to a chatroom in order to invite Romeo to join in. Current implementation: none File transfers - -------------- _`dis18`: Receiving a file in the context of a conversation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Juliet is talking to Romeo using a text or VoIP UI when he sends her a file in the context of that conversation. If it implements file transfer functionality, the text or VoIP UI should handle the file transfer; otherwise, the channel dispatcher should fall back to launching a standalone file transfer handler. _`dis19`: Receiving a file unexpectedly ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Juliet is not interacting with Romeo when he sends her a file. Some appropriate UI needs to be launched to indicate that the file has been offered. _`dis20`: Receiving a file in a collaborative application ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ File transfers might be a useful model for collaborative applications to use to transfer snapshots of state, or to transfer related files (e.g. in a word processor, you could receive an inline image that is embedded in the document). Tubes - ----- _`dis21`: Invited to One Laptop per Child Activities, as of early 2008 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An OLPC Activity instance encapsulates an instance of an application, zero or more D-Bus tubes and zero or more stream tubes to transfer messages or state between participants, and a text chatroom to discuss the activity. In the "1.0" protocol used in early 2008, each Activity instance is backed by an XMPP or Clique_ MUC (chatroom). Current implementation: we assume that the channels (Tubes, ROOM, foo) and (Text, ROOM, foo) correspond 1:1. Activity discovery is done out-of-band using OLPC-specific extensions, although we'd like to make some of it more standard (mainly invitations). Problems: * we don't want Tubes channels in their current form, since dispatching them is likely to be a bit of a nightmare if we can't rely on OLPC assumptions; we want one channel per Tube instead * in a less constrained environment, two different collaborative applications could conceivably share a MUC (the OLPC UI can't cause this to happen, but would likely get incredibly confused if it did) .. _Clique: http://telepathy.freedesktop.org/xmpp/clique.html _`dis`: Invited to be a client in an existing UDP/TCP client/server protocol ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (Use-cases req24, req25) Tybalt asks Juliet to help him fix a problem with his computer, and offers her a VNC connection to his computer so she can interact with his desktop. - - or - Romeo offers Mercutio and Benvolio access to an OpenArena server running on his local computer. .. vim:set sw=4 sts=4 et: -----BEGIN PGP SIGNATURE----- iD8DBQFIF1KOWSc8zVUw7HYRAilPAJ9dwIHRx95tFJa0SucMvOhEMXBm8QCgjnj0 TUuB4M+GEpiyok/yGE7LKgY= =8RNY -----END PGP SIGNATURE----- _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
