So I think Martin, Peter, and I share similar concerns here, and I'm inclined to turn those concerns into an objection to this charter.
So how does this sound for proposed comments on the charter (submitted as a formal objection)? Note that I've tried to turn the comments into a specific suggestion for a remedy, but I'm far from sure if that suggestion is the right one. I've avoided mentioning the comment about "further changes" in the specs that the existing working group has in CR, to avoid distracting from what I think is the main piece. But let me know if you see a good way to work it in. But I'd be particularly interested to hear if SC thinks this might be harmful rather than helpful to the end goal for some reason, or if he has other disagreements with this approach, or better suggestions for what remedy we should suggest. -David ===== The current situation with the API developed by this Working Group is that it is a API for a web page to interact with a connection between the web browser and a separate screen that exists entirely in a closed ecosystem. For example, a browser made by Google might connect to displays that support the proprietary Chromecast protocol, whereas one made by apple might connect to displays that support the proprietary AirPlay protocol. We know that parts of an Open Screen Protocol are in an early stage of development at https://github.com/webscreens/openscreenprotocol (as linked from the charter), and the goal of this work is to improve on this situation. We hope it will allow for interoperable discovery of, identification of, and communication with presentation displays. However, we're deeply concerned about chartering a second iteration of the work that continues building the Presentation API on top of a closed ecosystem, when the work to make the ecosystem more open has a lower priority. While we understand that the work on building an open ecosystem still requires incubation, we believe it should have the highest priority in this space. We believe that rechartering the Second Screen WG should wait until that work is ready to be in a working group, and that advancing the current specifications (developed under the existing charter) to Proposed Recommendation probably depends on this new work in order to demonstrate real interoperability, although we are open to other paths toward fixing this situation. On Thursday 2018-01-04 09:29 -0700, Peter Saint-Andre wrote: > +1 to Martin's feedback. > > On 1/3/18 10:19 PM, Martin Thomson wrote: > > Without the protocol pieces, this remains vendor-specific. We should > > comment on this and make it clear that we think that definition of a > > generic protocol for interacting with the second display has not been > > given sufficient priority. Allowing this to proceed without a generic > > protocol would be bad for the ecosystem. > > > > From what I can see, there seem to be a bunch of options that are > > described for the protocol, without extremely scant detail. Certainly > > not enough to implement anything. > > > > I'm concerned with the statement "This Working Group does not > > anticipate further changes to this specification" regarding the > > presentation API. I haven't reviewed this thoroughly, but there > > appear to be some gaps in rather fundamental pieces. For instance - > > and maybe this doesn't change the API at all - but the means of > > identification for screens is unclear. Some of these details are > > important, such as whether knowledge of a presentation URL is all the > > information necessary to use that URL (i.e., are they capability > > URLs?). > > > > On Thu, Jan 4, 2018 at 2:31 PM, Shih-Chiang Chien <sch...@mozilla.com> > > wrote: > >> The SecondScreen WG intended to move the protocol development to CG, and > >> will possibly move to IETF after the incubation phase. > >> The revised charter is trying to associate the work of CG to the timeline > >> of Presentation API development. > >> > >> At the meantime, WG will tackle the testability issue found while creating > >> test cases and cultivating Level 2 API requirements for advanced use cases. > >> > >> I'll vote to support this revised charter. > >> > >> Best Regards, > >> Shih-Chiang Chien > >> Mozilla Taiwan > >> > >> On Thu, Jan 4, 2018 at 10:08 AM, L. David Baron <dba...@dbaron.org> wrote: > >> > >>> The W3C is proposing a revised charter for: > >>> > >>> Second Screen Working Group > >>> https://w3c.github.io/secondscreen-charter/ > >>> https://lists.w3.org/Archives/Public/public-new-work/2017Dec/0000.html > >>> > >>> Mozilla has the opportunity to send comments or objections through > >>> Friday, January 52. (Sorry for failing to send this out sooner!) > >>> > >>> A diff relative to the current charter is: > >>> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014% > >>> 2Fsecondscreen%2Fcharter-2016.html&doc2=https%3A%2F%2Fw3c. > >>> github.io%2Fsecondscreen-charter%2F > >>> > >>> The participants in the working group are: > >>> https://www.w3.org/2000/09/dbwg/details?group=74168&public=1&order=org > >>> > >>> Please reply to this thread if you think there's something we should > >>> say as part of this charter review, or if you think we should > >>> support or oppose it. > >>> > >>> One longstanding concern for me with this work is to what extent it > >>> defines an API that lets an Google-made browser talk to a Google > >>> screen, and an Apple-made browser talk to an Apple screen, versus to > >>> what extent it allows any browser to talk to any screen that > >>> supports a particular piece of technology. I think there might > >>> have been some encouraging news on this front at TPAC in November, > >>> but I don't remember the details. But if there was, I'd rather > >>> expect it to be incorporated into this charter, but I don't really > >>> see that after a first read. I'm curious what others know and think > >>> about this issue. > >>> > >>> -David > >>> > >>> -- > >>> π L. David Baron http://dbaron.org/ π > >>> π’ Mozilla https://www.mozilla.org/ π > >>> Before I built a wall I'd ask to know > >>> What I was walling in or walling out, > >>> And to whom I was like to give offense. > >>> - Robert Frost, Mending Wall (1914) > >>> > >> _______________________________________________ > >> dev-platform mailing list > >> dev-platform@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-platform > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: PGP signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
