[Telepathy] new jingle engine for Gabble - update

[Peter Saint-Andre]

Robert McQueen wrote:
> Hi folks,
> 
> Peter Saint-Andre wrote:
>> About one session vs. many, we've had many discussions about that at
>> various XMPP meetings, but we've never reached any consensus. Maybe Rob
>> has more ideas on this topic.
> 
> :) What I said to Will which he hinted at somewhere in the original
> mists of this thread is that I don't think it's useful for clients to
> spend their time writing code which can deal with single sessions which
> are able to be a video call /and/ a file transfer /and/ a whiteboarding
> session. What would the UI be for managing such a multi-headed beast?
> 
> Given that each <content> in a <jingle> session has its own transport,
> there's not usually any performance benefit to putting unrelated content
> types into the same <jingle> session. It just makes something meaningful
> (the files in this session should be presented at once, or the
> audio/video streams in this session should be syncronised) into
> something meaningless, and harder to implement.
> 
> My gut feeling is therefore we should RECOMMEND against it, and allow
> clients to reject sessions which combine more than one content type, or
> reject attempts to add content of a different type to an existing
> session, unless in situations where we've defined it as explicitly
> useful. Now that audio and video are the same RTP content type, that's
> not a problem.

I agree.

> The one exception I can think of are my GTalk-inspired file-transfer
> ideas. In that case we'd like to have one pseudo-TCP <description> over
> an ICE <transport>, and multiple HTTP file <description>s over the
> pseudo-TCP <transport> within the same session. But we can burn that
> bridge when (if) we get to it.

Right.

> The analogy in my mind with existing XMPP stuff is the message stanza
> profile XEP-0226. Even though it's theoretically correct to put
> arbitrarily many extended child attributes in a <message> stanza, it's
> not actually useful (or desirable) for clients to be expected to deal
> with this. A <message> stanza which is simultaneously an invite, a
> feature negotiation, typing notification, HTML and plain text, geoloc
> etc is just crazy. Some XEPs are always allowed (AMP, if a server ever
> supports it :P), and others related to IMs are grouped, but most other
> exciting things should have their own <message>.

That analogy seems apt.

I'm glad we have consensus about this, at least between you and me. :)

Peter