- 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
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) Dom
Received on Friday, 18 June 2010 14:43:41 UTC