[Telepathy] Requestotron use-cases, part 4 (dispatching, harder cases)

[Simon McVittie]

-----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-----