W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2010

Sysinfo and access requests (was: API patterns and requirements)

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Fri, 18 Jun 2010 16:43:29 +0200
To: Rich Tibbett <rich.tibbett@gmail.com>
Cc: Wojciech Masłowski <wmaslowski@opera.com>, public-device-apis@w3.org
Message-ID: <1276872209.2228.106.camel@localhost>
Le vendredi 18 juin 2010 à 13:40 +0100, Rich Tibbett a écrit :

> It looks a little more complex but the application is presenting a
> clearer interaction flow in the first example than in the second.

Hmm… The first example is quite a bit messy to code with, in my view.

> The second example could also generate race conditions if we're not
> careful (e.g. if the web app requires that 'Power' completes before
> examining 'Network' but 'Network' returns first). 

That's not what I would call a race condition — using asynchronous calls
while expecting ordered responses is just foolish :)

> ...FWIW, I do question the SysInfo API model: if a user is required to
> authorize each SysInfo API call seperately it would probably make more
> sense for a web app to be able to request a bunch of System
> Information in a single API call (and hence a single permission
> request). The current SysInfo API does not have the ability to provide
> that yet :-(

I think this is something important to figure out; my model was that for
SysInfo, there would be either no permission request (due to the
relative harmless nature of the data requested), or at most one generic
permission request ("this web site wants to access information about the
device hardware and software status") which would authorize any
subsequent (or queued up) requests.

But that's probably worth discussing, and once we have a common view on
that question, expliciting in the draft.

(I still think the notion of serializing calls potentially make sense
for other APIs; it seems a very ill-fit for SysInfo in its current
shape, indeed)

Received on Friday, 18 June 2010 14:43:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:44 UTC