Re: Google/Mozilla Presentation API update

Regarding the API for message passing, wouldn't something simpler like a
subset of the WebSocket API be sufficient ?

Regarding restarting sessions, don't the proposals suffer from the same
problem of available device detection that the original API suffers from ?
That is, the onavailablechange event is indescriminate and even if it is
fired a call to requestSession may fail (no available devices / sessions
matching the parameters to the requestSession call). This corresponds to a
UX where the "present" icon is shown, but clicking it results in a failure.
There's no need for this bad UX, because we know, before showing the icon,
everything we need to know to make it more accurate.

The site needs to be able to ask for onavailablechange to be filtered by
the UA, with the filtering based on the same parameters that it would
provide to requestSession.

...Mark






On Wed, Aug 20, 2014 at 3:09 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Aug 20, 2014 at 1:54 PM, Anton Vayvod <avayvod@google.com> wrote:
> >> > I think we'd like to make sure the simple use cases that require only
> >> > DOMStrings are easy to implement, so we'd like to keep the messaging
> API
> >> > around for simplicity.
> >> >
> >> > Perhaps phasing could be used here as well: in v1 spec the messaging
> >> > API, make the RTCDataChannel a v2 feature.
> >>
> >> Agreed. The goal is to make sure that v2 is backwards compatible with
> v1.
> >
> > Won't we have to support the v1 version forever if the API v1 becomes
> > somewhat popular? It also would be yet another messaging API for the web
> > developers to handle. I think we'd better reuse an already existing
> > interface that fits the purpose well with a few fields and methods
> undefined
> > or being a noop reserved for the future (e.g. protocol could at some
> point
> > actually contain a hint as to what is going on if it turns out to be
> helpful
> > for developers). I assume we can state that it's just the interface that
> > matches the RTCDataChannel while the underlying protocol doesn't have to
> be
> > the one defined by the WebRTC spec.
>
> This is what I originally had hoped for too. However looking at the
> RTCDataChannel API, it seems horribly WebRTC specific. Not really a
> nice interface to expose if the backend isn't actually an
> RTCDataChannel.
>
> But what we could do is to expose an interface that is a subset of
> RTCDataChannel and only contains the pieces that we need, and has
> nothing else on it.
>
> That way we could in v2 simply change that interface to be an
> RTCDataChannel and this would be fully backwards compatible. So even
> if the v1 API becomes popular, any code that uses it will simply
> continue to work even in UAs that implement only the v2 API.
>
> / Jonas
>
>