[Telepathy] Telepathy spec. meeting: conference, splittable, call states

Simon McVittie simon.mcvittie at collabora.co.uk
Fri Nov 27 03:50:01 PST 2009


On Thu, 26 Nov 2009 at 13:01:02 +0000, Will Thompson wrote:
> === SupportsNonMerges property ===

Now that InitialInvitees exists, we might be able to use it to imply this.

> === How does a client actually add a third party to an existing 1–1
> conversation? ===
> [...]
> There is no way to do it with a single method call. It would be
> convenient to be able to add a requestable property InitialInvitees, so
> that clients could request a channel with:
> 
>  { ... ,
>    Conference.InitialChannels: [C1],
>    Conference.InitialInvitees: [Chris],
>  }

I've added this in my branch, along with InvitationMessage.

> === Which channels can you merge? ===
> 
> How do you know which of your contacts support being merged to a
> channel? For instance, you may have lots of contacts who support Jingle
> calls, but pretty much none of them will support Muji.
> ContactCapabilities doesn't really support this. Suggestions:
> 
> * use a channel class with InitialInvitees: [the contact's handle]. This
>   is a bit of a hack.
> * ''post-meeting refinement: put InitialInvitees or some other
>   Conference property in allowed.''
> * add a separate property to RequestableChannelClasses of some form.

Will points out that ContactCapabilities can conceivably include channel
classes where the handle type is not CONTACT. I'll look into this as a possible
way to represent the ability to do Room-related things.

> === Dead channels ===

Noted on my branch.

> === Splittable.Split() ===
> 
> How do you know which conference the channel you're trying to split is a
> part of?

Not addressed in my branch; I propose to defer this until after 0.19.0 in
the interests of getting some sort of draft merged.

> === Implicit hold/unhold ===
> 
> We could possibly require UIs to follow this pattern:
> 
> * Hold the conference
> * Split a channel
> * Unhold either the conference or the channel

Not addressed in my branch. I think we shouldn't be too specific about
the behaviour of Splittable until we've tried implementing it for GSM
channels, since we don't actually expect to implement it anywhere other than
GSM at the moment.

    S
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 793 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20091127/326879e0/attachment.pgp 


More information about the telepathy mailing list