Re: telepathy roadmap and media streaming

Jimen Ching wrote:
> Doesn't this imply automatic video stream connection?  What if I connect
> a digital video recorder with a firewire cable.  This dvr happens to be
> supported as a webcam.  This doesn't mean I want to create a video
> stream with the person I'm currently talking.

It's just an example; the actual policy of responding to device events
and doing something is obviously the responsibility of some desktop
component that decides these things.

> The API I proposed would require the user to explicitly publish the
> video stream for the remote end to subscribe.  Granted, this may not be
> how all IM protocols work.  But I don't think it prevents the user from
> configuring gossip to automatically publish and accept subscriptions of
> the video stream.  So the API supports your use case scenerio.

Not quite; the API you presented doesn't seem to distinguish a call that
has two streams (audio and video) and two seperate calls implying that
the video and audio streams are not necessarily related.

> My question is; should this API be exposed to the end user?  Or should
> it be hidden behind a user friendly interface that does most things
> automatically.

*end user* of the program, or end user of the API, ie the UI developer?
If the latter, yes.

> My goal is to develop an interface that allows the end user to make a vv
> transaction independent of the IM protocol being used.

That's good, because the telepathy API for streamed media channels is
designed to make audio/video calls independently of the protocol being
used. :)

> I.e. the use
> case for this vv transaction should be the same for SIP, Yahoo Messenger
> and Jingle.  I'm not sure where the directionality of the stream would
> be useful to the end user.

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.

> --jc

Regards,
Rob

-- 
Robert McQueen
Director, Collabora Ltd.