Prepare the spec for the First Public Working Draft by addressing existing issues

[avayvod]

The live version of the spec is located at http://avayvod.github.io/remote-playback.html
@mounirlamouri PTaL

[mounirlamouri]

Thanks for the change and the HTML output 😃
Can you list here which issues this is fixing? It might help looking how they are fixed in the document.

[anssiko]

@mounirlamouri see the F2F resolutions: #12 (comment)

Our plan of record is to have a publication ready FPWD by 11 July, see: #12 (comment)

[avayvod]

I'd say this PR fixes issues #4, #6, #7, #25, #39, #45, #47

[mounirlamouri]

I had a first look and I have a list of comments. They are in random order, some are close to nits, some are editorials and some are more about the content:

• Maybe "local remote playback" should be defined as "same device and browsing context"?
• Maybe you could make the "for short" versions of your terms the real versions. It's a bit confusing when both are being used.
• I think we might want to have watch() return an int and use it to cancel one callback; it's a common pattern.
• In the WebIDl, should the callback definition move before it's use or is this a common way of doing things?
• I don't like changeState(), it doesn't sound like the user will interact with this [though, we can bike shed the name in a follow-up]
• 6.2.1.1 seems to have a type "var>callback"
• You sometimes write "may", it should be "MAY"
• The algorithm you have for monitoring allows for many implementations. I think you should be more strict and say if monitoring is supported it MUST do X, otherwise it MUST do Y instead of a list of MAY.
• You sometimes have Foos, you can have Foos if you then point to the right definition I believe.
• Why do you keep the media element in the callback registry? Isn't the RemotePlayback object linked to a media element already? They should be the same, right?

[avayvod]

Thanks Mounir!
Comments inline:

• Maybe "local remote playback" should be defined as "same device and browsing context"?

Done.

• Maybe you could make the "for short" versions of your terms the real versions. It's a bit confusing when both are being used.

Done.

• I think we might want to have watch() return an int and use it to cancel one callback; it's a common pattern.

Done.

• In the WebIDl, should the callback definition move before it's use or is this a common way of doing things?

It seems common to define the callback below.

• I don't like changeState(), it doesn't sound like the user will interact with this [though, we can bike shed the name in a follow-up]

Changed to requestStateChange(). I'm trying to stay open to potential implementations that don't require device pickers.

• 6.2.1.1 seems to have a type "var>callback"

Done.

• You sometimes write "may", it should be "MAY"

Done.

• The algorithm you have for monitoring allows for many implementations. I think you should be more strict and say if monitoring is supported it MUST do X, otherwise it MUST do Y instead of a list of MAY.

Done.

• You sometimes have Foos, you can have Foos if you then point to the right definition I believe.

Done.

• Why do you keep the media element in the callback registry? Isn't the RemotePlayback object linked to a media element already? They should be the same, right?

Done.

[avayvod]

Cc @jernoble

[anssiko]

This PR seems to address #4, #6, #7, #25, #39, #45, #47 (as noted by @avayvod), as well as #36. I proactively updated our "FPWD issue tracker" to reflect the status after this PR has landed. My assessment is that the remaining open meta issue #41 does not impact the technical scope of the spec, and as such would not block the FPWD publication, thus I moved it to "good to land after FPWD bucket".

That means after this PR is merged, we should be good to use the latest ED spec as a basis for the FPWD publication. @tidoust can probably help prepare a FPWD snapshot.

Our plan is to merge this PR by the end of Monday, 11 July (unless we hear objections), and advance with the FPWD publication with a target to publish 14 July.

[avayvod]

Thanks Anssi! I'm okay with the plan to merge the PR on Monday and publish FPWD on Thursday next week.

[eric-carlson]

Promise<long> watchAvailability(RemotePlaybackAvailabilityCallback callback);
Promise       cancelWatchAvailability(optional long id);

I don't think "watch" is the right verb for these. Maybe "monitor" would be better?

[mounirlamouri]

We used "watch" because it's a pattern used by the Geolocation and NFC APIs. Is there a semantic difference between the "watch" used by these APIs and the one used in this one? FWIW, I think "monitor" is fine but I would prefer that we have consistency across the platform.

[avayvod]

I agree with Mounir on our stance w.r.t. the name for observing availability.