[Bug 24939] Interface for upgrading chats/calls to multi-user

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24939


Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Status Whiteboard|                            |specmeet?




--- Comment #10 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-11-17 09:47:04 PST ---
(In reply to comment #9)
> * Should C1 close automatically? Why/why not?
> * Should C3 close automatically? Why/why not?

Sjoerd and I concluded that it's least astonishing if neither of them closes.

> * How do we solve the race condition mentioned in Comment #6?

Sjoerd and I concluded that UIs wanting this auto-accept behaviour should
implement it via cooperation between the approver and the handler:

* Approver knows about this upgrading API, sees that the channel is an upgrade
of a channel that's being handled, and lets it go past silently

* no race is involved, because the Approver is (presumably) single-threaded

* an Approver that's actively co-operating with a Handler can always learn what
channels that Handler is handling, by asking it (via the normal Handler API or
otherwise)

An API is proposed in comment 6 of Bug #24906:
http://bugs.freedesktop.org/show_bug.cgi?id=24906#c6

Possible concrete implementations of that API:

XMPP
====

Channels do not implement Splittable.

This description only covers Text: Muji will have analogous APIs for Call.

Capability discovery
--------------------

RequestableChannelClasses includes two channel classes, as follows:

For upgrading 1-1 chats to an unspecified (generated) chatroom:

    Fixed:
        ...Channel.ChannelType: ...Channel.Type.Text
    Allowed:
        ...Channel.Interface.Conference.InitialChannels
        ...Channel.Interface.Conference.SupportsNonMerge

and for upgrading 1-1 chats to a specific chatroom:

    Fixed:
        ...Channel.ChannelType: ...Channel.Type.Text
        ...Channel.TargetHandleType: ROOM
    Allowed:
        ...Channel.TargetHandle
        ...Channel.TargetID
        ...Channel.Interface.Conference.InitialChannels
        ...Channel.Interface.Conference.SupportsNonMerge

Use cases
---------

X1. Joining or creating a chatroom (as implemented in Gabble 0.8.x):

    EnsureChannel({
        ...Channel.ChannelType: Channel.Type.Text,
        ...Channel.TargetHandleType: ROOM,
        ...Channel.TargetID: 'lolz at conf.example.com',      # or TargetHandle
        })
    returns a channel with type Text, TargetHandleType = ROOM, and a room
    handle representing lolz at conf.example.com.

X2. Creating a chatroom with an unspecified name and not inviting anyone:

    CreateChannel({
        ...Channel.ChannelType: Channel.Type.Text,
        ...Channel.Interface.Conference.InitialChannels: [],    # or omitted
        })
    returns a channel with type Text, TargetHandleType = ROOM, and a room
    handle representing <some UUID>@conf.example.com.

    (Behind the scenes, this either uses XEP-0045 §10.1.4, or just generates
    a UUID; XEP-0045 §10.1.4 would require us to disco the server, which
    never yields a reply in Google Talk PMUC, so we might as well just
    generate a UUID.)

X3. Continuing one or more chats in a chatroom:

    Let C1, C2, ... be arbitrarily many Text channels with
    TargetHandleType = CONTACT, whose TargetIDs are the JIDs J1, J2, ...

    CreateChannel({
        ...Channel.ChannelType: Channel.Type.Text,
        ...Channel.Interface.Conference.InitialChannels: [C1, C2, ...],
        })
    returns a channel with type Text, TargetHandleType = ROOM,
    and a room handle representing <some UUID>@conf.example.com,
    to which the contacts J1, J2, ... have been invited.

    (Behind the scenes, this does the same as X2, then sends invitations to
    each of J1, J2, ..., with each invitation containing the appropriate
    <continue/> element from among C1, C2, ...)

X4. Continuing one or more chats in a specific chatroom:

    Let C1, C2, ... be arbitrarily many Text channels with
    TargetHandleType = CONTACT, whose TargetIDs are the JIDs J1, J2, ...

    EnsureChannel({
        ...Channel.ChannelType: Channel.Type.Text,
        ...Channel.Interface.Conference.InitialChannels: [C1, C2, ...],
        ...Channel.TargetHandleType: ROOM,
        ...Channel.TargetID: 'lolz at conf.example.com',      # or TargetHandle
        })
    returns a channel with type Text, TargetHandleType = ROOM,
    and a room handle representing lolz at conf.example.com,
    to which the contacts J1, J2, ... have been invited.

    (Behind the scenes, this does a normal MUC join if necessary, then sends
    invitations to each of J1, J2, ..., with each invitation containing the
    appropriate <continue/> element from among C1, C2, ...)

X5. Merging a chat C1 into a specified Conference channel Cn

    Either do X4 with the appropriate handle, or call
    Conference.Merge(C1) on Cn. (Behind the scenes, this invites the peer
    from C1, as for X4.)

    (In practice, using Conference.Merge is preferred if you already have
    a Conference channel, because this will also work for MSN/Skype.)

MSN/Skype
=========

Channels do not implement Splittable.

Capability discovery
--------------------

RequestableChannelClasses includes one channel class
for upgrading 1-1 chats to an unspecified (generated) chatroom:

    Fixed:
        ...Channel.ChannelType: ...Channel.Type.Text
    Allowed:
        ...Channel.Interface.Conference.InitialChannels
        ...Channel.Interface.Conference.SupportsNonMerge

Use cases
---------

M1. Continuing one or more chats in a chatroom:

    Let C1, C2, ... be arbitrarily many Text channels with
    TargetHandleType = CONTACT, whose TargetIDs are the JIDs J1, J2, ...

    CreateChannel({     # this is the same method call as for X3
        ...Channel.ChannelType: Channel.Type.Text,
        ...Channel.Interface.Conference.InitialChannels: [C1, C2, ...],
        })
    returns a channel with type Text, TargetHandleType = NONE,
    into which the contacts J1, J2, ... have been forcibly added.

    Behind the scenes, the channel has "stolen" the switchboard
    from C1; the peers in C2, ... will see it as a new chat, the peer in
    C1 will see it as a distinct chat.

M2. Creating a new switchboard and not initially inviting anyone (not very
    useful, but allowed for symmetry):

    CreateChannel({     # this is the same method call as for X2
        ...Channel.ChannelType: Channel.Type.Text,
        ...Channel.Interface.Conference.InitialChannels: [],    # or omitted
        })
    returns a channel with type Text, TargetHandleType = NONE, with no
    associated switchboard; a new switchboard will be allocated as soon
    as someone is invited

M3. Merging a chat C1 into a specified Conference channel Cn

    Call Conference.Merge(C1) on Cn. (Behind the scenes, this just invites
    the peer from C1 - they don't see any indication that you consider it to
    be a continuation of C1.)


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.