w3c/remote-playback

Consistency with Presentation API

Closed this issue · 6 comments

chrisn commented

The Remote Playback API has different method names for actions that are conceptually very similar to the Presentation API.

For example, the Remote Playback API has watchAvailability(), which takes a callback parameter, whereas the Presentation API has getAvailability() that returns a PresentationAvailability object with an onchange event handler. Also, start() in the Presentation API is prompt() in the Remote Playback API.

Should we try to align these, for consistency? I think this may help with use of these APIs by application developers.

mounirlamouri commented

The Remote Playback API is a higher level API which explains some of these disparities. start() and prompt() are not the same thing. prompt() will show a platform specific UI while start() should do start the connecting process. Calling start() while connected means that you want to connect to something else. Calling prompt() while connected, means that you want to show some UI - details of which are again platform specific.

Regarding the availability. It was one of the main design discussion because we wanted something simpler than PresentationAvailability. We initially had a design close to PresentationAvailability but moved away from it based on implementers' feedback.

chrisn commented

Thanks @mounirlamouri. I think a simpler design benefits both users and implementers. I guess my question then is whether the Presentation API could use a similar callback approach rather than PresentationAvailability. The algorithm steps for each look pretty similar, but maybe there's some subtlety I'm missing that means the availability object is needed.

tidoust commented

If I'm not mistaken, we discussed this during our F2F in Mountain View in May 2016. I raised a similar question then, captured in the minutes as:

Francois: Does this discussion affect the Presentation API as well?
Mark: I would have to think about similarity of use cases, but it might be a good idea to raise an issue.
Anssi: That's use case based.
Mark: the bar is higher for the Presentation API, because the spec is mostly stable now.
Anssi: I agree.

http://www.w3.org/2016/05/24-webscreens-minutes.html#item03

Essentially, it's a good idea in theory but it comes in a bit late for the Presentation API, which has been mostly stable for some time now.

chrisn commented

OK, I'd be happy to raise an issue if we think it'd be in scope for a Presentation API v2.

mounirlamouri commented

@chrisn I'm going to close this issue. Please file an issue with the Presentation API if you believe that it should be changed.

markafoltz commented

The main differences I see in the RP API availability interface:

  • The user agent has to keep track of a list of ids for registered availability callbacks instead of the lifetime of availability objects.
  • The Web developer registers callbacks instead of using the EventTarget interface.
  • The Web developer can cancel an availability callback or all callbacks.
  • The Web developer doesn't have a platform object to get the current availability. They will need to track this on their own (along with the id they got if they want to cancel later.)

It seems to be a tradeoff between developer vs. implementer convenience. Based on developer feedback, I could see adding a cancel() method to PresentationAvailability which would signal the user agent to stop monitoring availability for that request.