- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Fri, 22 Aug 2014 12:39:59 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: "mark a. foltz" <mfoltz@google.com>, Anton Vayvod <avayvod@google.com>, Marco Chen <mchen@mozilla.com>, Wesley Johnston <wjohnston@mozilla.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Evelyn Hung <ehung@mozilla.com>
On 21 Aug 2014, at 03:44, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Aug 20, 2014 at 5:30 PM, mark a. foltz <mfoltz@google.com> wrote: >>> In order to make this flow slightly more efficient we could in step 8 >>> include in the "onavailablechange" event include a flag indicating >>> that a presentation for the same origin is already running. That way >>> AwesomeGame could avoid doing step 9 in most cases when AwesomeGame >>> wasn't running on the TV. >> >> I think the requestSession check should be able to be computed quickly >> (either the browser is aware of the presentation or not) so perhaps this >> isn't necessary. > > I don't feel strongly either way. > > Having the information available synchronously in the > onavailablechange event handler (through a property) is somewhat > simpler than enabling getting the information asynchronously (through > a call to requestSession). But it doesn't make a big difference. > > We can certainly leave the property out for now, it's easier to add it > later based on author feedback than to remove it later based on it not > being used. +1 Generally, this principle (“When in doubt, leave it out.”) has worked very well in API design, and is especially well-suited for Web APIs for which deprecation may be impossible or at least very painful, depending on usage. Thanks, -Anssi
Received on Friday, 22 August 2014 12:40:55 UTC