[Telepathy] Requestotron use-cases, part 3 (harder requests)

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are some of the more complicated use-cases for requests.

HTML at <http://people.collabora.co.uk/~smcv/request.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

Ad-hoc chatrooms
- ----------------

This section refers to protocols like MSN, where what appears to be a 1-1
conversation is actually just an unnamed chatroom into which other users
can be invited.

_`req13`: Chat from chat UI (MSN)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(The same as req1_, but Romeo and Juliet are using a "fully correct" MSN
implementation like telepathy-butterfly, or some similar protocol.)

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.

Hypothetical implementation::

    if a channel with GetHandle() -> (NONE, 0) exists, and its set of members
    contains Juliet's handle, and no other handles other than Romeo's:
        foreground its window or tab
    else:
        either:
            RequestChannel (Text, CONTACT, juliet, suppress_handler=TRUE)
        or:
            RequestChannel (Text, NONE, 0, suppress_handler=TRUE)
            AddMembers([juliet])

(Capability discovery can be used to decide whether to use the first or
second way to request a channel - the second must be used if we intend to
invite others to the channel later)

Problems:

* Determining whether we already have a channel to Juliet becomes harder
  than in req1_

_`req14`: Ad-hoc chatroom from chat UI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Romeo wants to talk to both Mercutio and Benvolio in an ad-hoc chatroom.
He selects them both from a contact list, or types in both their usernames.

Hypothetical implementation::

    if a channel with GetHandle() -> (NONE, 0) exists, and its set of members
    contains exactly (Mercutio, Benvolio, Romeo):
        foreground its window or tab
    else:
        RequestChannel (Text, NONE, 0, suppress_handler=TRUE)
        AddMembers([mercutio, benvolio])

Problems:

* Determining whether we already have an appropriate channel is race-prone
  and inconvenient

_`req15`: Ad-hoc chatroom preferred
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Romeo wants to talk to both Mercutio and Benvolio in an ad-hoc chatroom.
He selects Mercutio from a contact list, or types in Mercutio's username,
then invites Benvolio to the chatroom too.

Hypothetical implementation::

    if a channel with GetHandle() -> (NONE, 0) exists, and its set of members
    contains exactly (Mercutio, Romeo):
        foreground its window or tab
    else if Capabilities interface indicates support for inviting contacts
    to ad-hoc chatrooms:
        RequestChannel (Text, NONE, 0, suppress_handler=TRUE)
        AddMembers([mercutio])
        # when Benvolio is invited...
        AddMembers([benvolio])
    else:
        RequestChannel (Text, CONTACT, [mercutio], suppress_handler=TRUE)
        Do not offer UI for adding Benvolio

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

_`req16`: Chat from address book (MSN)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(The same as req2_, but Romeo and Juliet are using a "fully correct" MSN
implementation like telepathy-butterfly, or some similar protocol.)

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

Possible 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
    CM does... something?
    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:

* The problems of req2_

* Should the CM pick an existing channel containing only Romeo and Juliet
  (if available), or create a new one?

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

_`req17`: Ad-hoc chatroom from address book
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The same as req14_ but from an address book.

Hypothetical implementation:

* address book asks MC for a channel with (Text, NONE, 0)

* it's handled by the default channel handler

* address book adds Mercutio and Benvolio with AddMembers

Problems:

* Surely the "address book" (which might instead be e.g. the GNOME menu)
  shouldn't need to know how to interact with Telepathy in this much
  detail?

* The chat UI getting people inserted into "its" channel by another process
  is quite weird

* No way for the chat UI to re-use an existing channel

* Do protocols like MSN allow us to have two channels with the same members?

_`req18`: Ad-hoc chatroom embedded in collaboraborative 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: unclear

Possible implementation::

    RequestChannel (Text, NONE, 0, suppress_handler=TRUE)
    AddMembers ([mercutio])

Problems:

* Are we allowed to have two MSN switchboards with the same two members?

_`req19`: Upgrading a 1-1 chat to a named or ad-hoc chatroom
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Same as http://www.xmpp.org/extensions/xep-0045.html §7.6. XMPP does this
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)?

File transfers
- --------------

_`req20`: Sending a file in the context of a conversation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Romeo is talking to Juliet using a text or VoIP UI, and wishes to
send Juliet a file in the context of that conversation.

_`req21`: Sending a file from a file manager
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Romeo right-clicks on a file in his file manager, chooses a "Send to User"
option and chooses to send it to Juliet.

_`req22`: Sending a file automatically in a collaborative application
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

While collaborating on a document with Mercutio, Romeo inserts an embedded
image into the document. The collaborative application could usefully choose
to represent this by a file transfer.

Tubes
- -----

_`req23`: 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

_`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.

_`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.

..
  vim:set sw=4 sts=4 et:
-----BEGIN PGP SIGNATURE-----

iD8DBQFIF01ZWSc8zVUw7HYRAvVBAJ4rW/V1tS1POVq2L8WLtfUPlJfVmwCg743Q
lf58STxKFjxKoLCANvFKHno=
=Ppm1
-----END PGP SIGNATURE-----