Re: Google/Mozilla Presentation API update

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

Received on Wednesday, 20 August 2014 22:10:50 UTC