Hi all, The Remote Playback API is now targeting to ship to M121 on Win/Mac/Linux. There's no change to the spec or the API. The Chrome Status entry has been updated. On Wednesday, November 30, 2016 at 9:39:53 AM UTC-8 Anton Vayvod wrote:
> On Wed, Nov 30, 2016 at 11:33 AM Jochen Eisinger <joc...@chromium.org> > wrote: > >> I was wondering why there's no security & privacy consideration section >> (open issue https://github.com/w3c/remote-playback/issues/67)? >> > > We don't expect to have more there than the Presentation API ( > https://w3c.github.io/presentation-api/#security-and-privacy-considerations) > since Remote Playback API doesn't have the receiver browser context or > identifiers for reconnection to a device and exposes only one bit of > information in a similar way about device availability. > > That said, the issue definitely slipped through and I'll look into > updating the issue with the self-questionnaire responses and adding a draft > section to the spec now. Thanks for noticing! > > >> >> On Mon, Nov 28, 2016 at 8:34 PM Anton Vayvod <ava...@chromium.org> wrote: >> >>> ...and an after-holiday ping :) >>> >>> >>> On Tue, Nov 22, 2016 at 12:23 PM Anton Vayvod <ava...@chromium.org> >>> wrote: >>> >>>> A gentle ping. We'd need one more LGTM in order to ship. Thanks! >>>> >>>> >>>> On Fri, Nov 18, 2016 at 8:00 AM Philip Jägenstedt <foo...@chromium.org> >>>> wrote: >>>> >>>>> LGTM2 >>>>> >>>>> On Fri, Nov 18, 2016 at 2:03 AM Chris Harrelson <chri...@chromium.org> >>>>> wrote: >>>>> >>>>>> LGTM1 >>>>>> >>>>>> On Thu, Nov 17, 2016 at 1:24 PM, Anton Vayvod <ava...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 17, 2016 at 2:43 AM Philip Jägenstedt < >>>>>>> foo...@chromium.org> wrote: >>>>>>> >>>>>>>> On Thu, Nov 17, 2016 at 12:59 AM Anton Vayvod <ava...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Comments inline: >>>>>>>>> >>>>>>>>> On Wed, Nov 16, 2016 at 1:40 AM Philip Jägenstedt < >>>>>>>>> foo...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> There are some open issues >>>>>>>>>> <https://github.com/w3c/remote-playback/issues>, most filed by >>>>>>>>>> Chromium developers. Can you go through and resolve as many as >>>>>>>>>> possible? >>>>>>>>>> Issues which can't possibly change observable behavior are fine to >>>>>>>>>> leave, >>>>>>>>>> of course. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Mounir and I looked at the issues today. There's one minor issue >>>>>>>>> that might result in an observable behavior change depending on what >>>>>>>>> we >>>>>>>>> agree at: https://github.com/w3c/remote-playback/issues/63. >>>>>>>>> >>>>>>>>> We're going to resolve it asap (I'll update this thread). >>>>>>>>> >>>>>>>> >>>>>>>> Great! As long as you're confident that it'll be resolved in a >>>>>>>> specific way, that other implementers will support it, and that you'll >>>>>>>> match that when shipping, this intent need not block, but if there's >>>>>>>> no >>>>>>>> hurry we can just wait for it to be resolved. >>>>>>>> >>>>>>> >>>>>>> We checked how Safari is implementing >>>>>>> <https://www.google.com/url?q=https%3A%2F%2Fbugs.webkit.org%2Fattachment.cgi%3Fid%3D292263%26action%3Dprettypatch&sa=D&sntz=1&usg=AFQjCNE4T6Lo6DjBj_CPQCdgwRSsIpbzwg> >>>>>>> >>>>>>> and resolved the issue with no change to the spec. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Browsing the IDL, I see that the implementation doesn't have the >>>>>>>>>> "connecting" RemotePlaybackState enum value, is that the tip of an >>>>>>>>>> iceberg >>>>>>>>>> or would it be trivial to implement? >>>>>>>>>> >>>>>>>>> >>>>>>>>> This was actually just a missing enum value in the idl file, the >>>>>>>>> rest of the iceberg has been implemented before the Intent to Ship :) >>>>>>>>> >>>>>>>>> I've fixed the IDL, thanks for noticing (I wonder if Blink should >>>>>>>>> verify enum values used?). >>>>>>>>> >>>>>>>> >>>>>>>> Yes, we should! The predictability program is working this quarter >>>>>>>> on Blink IDL spec sync >>>>>>>> <https://docs.google.com/document/d/1yKwaxvgm-8Ljuo4equXKaPey-HNhjyLnvp89cxscnhs/edit?usp=sharing>, >>>>>>>> >>>>>>>> and the tooling that +Mark Dittmer is building will eventually >>>>>>>> allow us to see what differences there are for IDL files across Blink, >>>>>>>> and >>>>>>>> possible also have it as a presubmit check in the long term. >>>>>>>> >>>>>>> >>>>>>> Great to hear! >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Is there a shared test suite for this, so that other implementers >>>>>>>>>> can have some confidence that they're passing the same tests as our >>>>>>>>>> implementation? I realize that automated tests for the actual >>>>>>>>>> behavior >>>>>>>>>> would require something that doesn't exist yet, but the >>>>>>>>>> surface-level APIs >>>>>>>>>> should be possible to test. >>>>>>>>>> >>>>>>>>> >>>>>>>>> We have some test-harness based tests >>>>>>>>> <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/media/remoteplayback/> >>>>>>>>> >>>>>>>>> for the various edge cases that don't require actual remote playback >>>>>>>>> devices. The Second Screen WG is working on a test suite for the >>>>>>>>> Presentation API atm, I expect their setup to work well for the >>>>>>>>> Remote >>>>>>>>> Playback API too. >>>>>>>>> >>>>>>>>> Do you have an example in mind of an additional tests we could >>>>>>>>> write today though? >>>>>>>>> >>>>>>>> >>>>>>>> It looks like only prompt-twice-throws.html uses internals, so >>>>>>>> contributing the others to web-platform-tests would be great. To be >>>>>>>> clear, >>>>>>>> this is *not* yet a required part of any process, because >>>>>>>> exporting tests isn't super easy, yet >>>>>>>> <https://docs.google.com/document/d/1JgPTyIWmjlXyhyatiZ9A6fSbUQPjCyM26budEY90VDE/edit?usp=sharing> >>>>>>>> . >>>>>>>> >>>>>>>> In addition to those tests, idlharness.js tests might be useful >>>>>>>> just to cover the things that can be automatically tests based on the >>>>>>>> spec's IDL alone, which cuts down on some very boring tests like >>>>>>>> checking >>>>>>>> that RemotePlayback does in fact inherit directly from EventTarget and >>>>>>>> so >>>>>>>> on. >>>>>>>> >>>>>>> >>>>>>> Ok, we've filed a tracking issue >>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=666465#c1> >>>>>>> for this work and will target M57. >>>>>>> >>>>>>> >>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "blink-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to blink-dev+...@chromium.org. >>>>>>> >>>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b7c6fa5b-ff72-460d-8cd1-8cf1591317d5n%40chromium.org.
