LGTM!

On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron <dba...@dbaron.org> wrote:

> 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)
>
> _______________________________________________
> 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