- From: Mark Watson <watsonm@netflix.com>
- Date: Wed, 20 Aug 2014 18:15:37 -0700
- To: "mark a. foltz" <mfoltz@google.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Anton Vayvod <avayvod@google.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, Marco Chen <mchen@mozilla.com>, Wesley Johnston <wjohnston@mozilla.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Evelyn Hung <ehung@mozilla.com>
- Message-ID: <CAEnTvdBEvF9OVxfK_kW28AZCSF+b6HE7akfFikwFbFW-AmFVfg@mail.gmail.com>
On Wed, Aug 20, 2014 at 5:44 PM, mark a. foltz <mfoltz@google.com> wrote: > Correction to my earlier post in bold: > > I think negotiation of the active controller would happen at a level above > the connection status of individual pages to the presentation. Meaning, > the application could implement a leader election protocol using the > messaging channel, and message *to the losers* to close their connections > (or assume a passive role). > > m. > > My assumption is that the presenting page allows simultaneous connection > from multiple controlling pages. The spec does not seem entirely clear on > when the PresentationSession transitions between connected to disconnected, > and we'll have to tighten that up to support reconnection and multiple > controlling pages. > > On Wed, Aug 20, 2014 at 5:42 PM, mark a. foltz <mfoltz@google.com> wrote: > >> On Wed, Aug 20, 2014 at 5:10 PM, Mark Watson <watsonm@netflix.com> wrote: >> >>> >>> >>> >>> On Wed, Aug 20, 2014 at 5:04 PM, Jonas Sicking <jonas@sicking.cc> wrote: >>> >>>> On Wed, Aug 20, 2014 at 4:47 PM, Mark Watson <watsonm@netflix.com> >>>> wrote: >>>> > Regarding the API for message passing, wouldn't something simpler >>>> like a >>>> > subset of the WebSocket API be sufficient ? >>>> >>>> The messaging subset of RTCDataChannel is effectively the same as the >>>> messaging subset of WebSocket. This is coincidental since >>>> RTCDataChannel intentionally tried to have the same messaging API as >>>> WebSocket. >>>> >>>> So what we should do is to have an object with the following interface: >>>> >>>> interface PresentationAPISocketChannelWithATwist { >>>> // The twist is that it's both a socket and a channel. >>>> >>>> void send((DOMString or Blob or ArrayBuffer or ArrayBufferView) data); >>>> void close (); >>>> >>>> attribute BinaryType binaryType; >>>> readonly attribute unsigned long bufferedAmount; >>>> readonly attribute ?? readyState; // unclear which one we should >>>> follow. >>>> >>>> attribute EventHandler onmessage; >>>> attribute EventHandler onopen; >>>> attribute EventHandler onerror; >>>> attribute EventHandler onclose; >>>> }; >>>> >>> >>> Looks great. >>> >>> >>>> >>>> >>>> > Regarding restarting sessions, don't the proposals suffer from the >>>> same >>>> > problem of available device detection that the original API suffers >>>> from ? >>>> > That is, the onavailablechange event is indescriminate and even if it >>>> is >>>> > fired a call to requestSession may fail (no available devices / >>>> sessions >>>> > matching the parameters to the requestSession call). This corresponds >>>> to a >>>> > UX where the "present" icon is shown, but clicking it results in a >>>> failure. >>>> > There's no need for this bad UX, because we know, before showing the >>>> icon, >>>> > everything we need to know to make it more accurate. >>>> >>>> No. The page would simply call requestSession() with resumeOnly set to >>>> true before displaying any UI. If the connection succeeds the page >>>> would display the "connected" UI rather than a "present" icon. If the >>>> connection fails, then it would show a "present" icon (unless the >>>> onavailablechange fires again and lets the page know that the TV is no >>>> longer available). >>>> >>> >>> I can see how that works, but what if the site doesn't want to >>> automatically reconnect ? Suppose the presentation id has been shared >>> across a bunch of devices but the application model is that there is only >>> one active controller at a time ? Reconnecting would correspond to wresting >>> control from the existing controller, which the user might not want. >>> >> >> I think negotiation of the active controller would happen at a level >> above the connection status of individual pages to the presentation. >> Meaning, the application could implement a leader election protocol using >> the messaging channel, and message to close their connections (or assume a >> passive role). >> >> My assumption is that the presenting page allows simultaneous connection >> from multiple controlling pages. The spec does not seem entirely clear on >> when the PresentationSession transitions between connected to disconnected, >> and we'll have to tighten that up to support reconnection and multiple >> controlling pages. >> > Ok, so if multiple simultaneous connections are allowed we will need some way to tell the presenting page when controllers come and go and which controller each message is from, right ? In that case, I guess there is no downside to calling requestSession() automatically to re-establish all known prior sessions and thereby finding our which are active. Any "single controller" application model would then be implemented by the application. Still, I don't think the availability filtering problem is going to go away and I'd prefer that we address it. ...Mark > >> m. >> >> >
Received on Thursday, 21 August 2014 01:16:05 UTC