[Gossip-dev] telepathy roadmap and media streaming

[Jimen Ching]

On Fri, 29 Sep 2006, Robert McQueen wrote:
> You need to know whether you're expecting incoming video to know whether
> you should display a video output window, whether you have incoming
> audio to present a mute button and a volume control. You should show the
> user when their audio and their video is being sent, perhaps offering an
> outgoing audio mute, and a preview windoiw. You need to know when the
> remote end has asked to change an incoming audio stream to an outgoing
> one, because otherwise the user could be streaming audio without knowing
> it... I think most of these directionality change events are relevant to
> the user or to configuring the UI correctly.

First, I should clarify my proposed API.  This API is for the UI 
developer, which will translate to an interface to the Gossip end-user. 
I.e. if there's no API for the UI developer, the Gossip end-user won't 
have that interface either.  I'm making the assumption that any UI 
developer API that is defined, will be completely exposed to the Gossip 
end-user.  Since this is an application API, I don't see the point in 
defining an API that doesn't affect both the UI developer and the Gossip 
end-user.

Concerning your scenerios above, I've never considered the use case of 
initiating an out-going voice call but only 'receiving' audio data (i.e. 
not generating audio data).  Basically, this is like initiating a 
bi-directional channel, and muting the outgoing stream immediately.  I 
guess this could be useful under a broadcast use case scenerio.

I should also note; the API I proposed has inherent directionality.

 	request_voice_chat (establish bi-dir outgoing channel)
 	cancel_voice_chat (cancel the above)
 	accept_voice_chat (complete bi-dir incoming channel)
 	reject_voice_chat (close bi-dir incoming channel)

The video channel API has A similar API.  The 'publish' API is for 
outgoing channels.  Granted, this does separate the voice and video 
streams.  I guess I made the assuption that we want to do this.  Guess 
that may be a bad assumption.

It seems what we need to do first is to define the use cases we want to 
support.  Let's end this thread here, and I'll start another one for 
discussing what capability we want to support with the media streaming 
feature.

--jc
-- 
Jimen Ching (WH6BRR)      jching at flex.com     wh6brr at uhm.ampr.org