W3C home > Mailing lists > Public > public-secondscreen@w3.org > April 2017

[remote-playback] Interoperability concerns by lack of a common denominator in transport

From: Sangwhan <sysbot+gh@w3.org>
Date: Tue, 11 Apr 2017 09:50:50 +0000
To: public-secondscreen@w3.org
Message-ID: <issues.opened-220897112-1491904249-sysbot+gh@w3.org>
cynthia has just created a new issue for https://github.com/w3c/remote-playback:

== Interoperability concerns by lack of a common denominator in transport ==
This is a follow-up from the TAG review request.

I haven't done a particularly good job at getting back to the group with the feedback we had, I apologize for that. The API side of the spec is sound, and I don't see anything that would be a serious issue worth opening issues for - but the elephant in the room is interoperability.

Setting aside the fact that this is already being implemented and shipping, with each implementation possibly shipping using some form of proprietary transport - we think that the spec not defining a common denominator transport mechanism in a normative section is problematic and would hurt interoperability, and potentially jeopardize the usefulness of the API.

If implementations ship with incompatible transports, we will be stuck in a situation where content authors have to rely on sniffing and whitelisting, either in the form of code or documentation, which is undesirable - and this encourages tight coupling between the remote playback device and the user agent.

>From what I see, with the spec as of today: (Correct me if I am wrong)
 - Android TV as a remote playback device will most likely not work from Safari, and Firefox will most like not be able to stream to an Apple TV.
 - Users would have to randomly try different browsers (although intuitively, compatible pairing for most cases would be rather obvious) until they find something that works.
 - On the same computer, you would see the remote playback device on some browsers and not on others due to this.

This doesn't seem like the kind of usability we should be promoting. I've brought this up with the team, and @w3ctag does not consider this specification ready for implementation for these reasons.

I have been made aware of the open screen protocol, would it be possible to accelerate the development of that and include that as a common denominator requirement for interoperability before we end up in another sniffing/whitelisting situation?


Please view or discuss this issue at https://github.com/w3c/remote-playback/issues/74 using your GitHub account
Received on Tuesday, 11 April 2017 09:50:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 11 April 2017 09:50:57 UTC