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

Reply via email to