Re: Presentation API changes proposal

Hi Mark,

happy to answer your question.
the UA would need to be able to establish the channel between the
controller and the receiver (using Cast low-level protocols in the
Chromecast case) but the messaging protocol format is up to the developer
of the sender and the receiver. If the sender/receiver use Cast Javascript
SDK built on top of the Presentation API, there'll be a set of convenient
predefined messages like play/pause/stop/etc and a possibility to send
custom messages like in the TicTacToe example [1]. Otherwise, the UA
provides a way to send JSON objects from the controller to the receiver and
back and that's it.

Thanks,
Anton.

[1]
https://github.com/googlecast/cast-android-tictactoe/blob/master/receiver/tictactoe.js#L94


On Fri, Jan 10, 2014 at 1:53 PM, Mark Finkle <mfinkle@mozilla.com> wrote:

>
>
> ------------------------------
>
>
>  One possibility is to add another event "onconnected" or similar to the
>>> navigator.presentation object and deliver a MessagePort there? This
>>> event would fire only on pages that are opened as "receiver
>>> applications" in Chromecast terms. And this page's onunload would
>>> correspond to the PresentationWindow's onclose for example.
>>>
>>
> Sounds good. In case of different UAs though, the receiving end might be
> implemented differently. Chromecast, for example, provides its receiver SDK
> to use by the receiver applications. The UA hosting the controller would
> transform MessagePort events into Chromecast events and send it towards the
> device that would forward it to the player in some form.
>
> I might be misunderstanding, but this sounds like the UA would need to be
> aware of the messaging protocol format of any device (Chromecast in this
> case) and provide transformations. Is the messaging protocol in question
> the RemoteMedia system used by Chromecast? Isn't it possible for Chromecast
> "applications" to create custom protocols too? I'm thinking about the
> TicTacToe sample app.
>
>