- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 7 Oct 2009 16:28:11 +0000 (UTC)
- To: Robin Berjon <robin@robineko.com>
- Cc: public-device-apis@w3.org
On Wed, 7 Oct 2009, Robin Berjon wrote: > > Option A: window.navigator.device > Option B: window.device I don't think it's possible to make a single decision. Assuming these APIs are intended for use on the broad Web (which isn't entirely clear to me), we are likely to be constrained in all kinds of ways, e.g. it may be that window.device clashes with a script on newegg.com or amazon.com and we can't use that identifier, or it may be that we need a constructor and so we need an interface at the global scope level, or it may be that some API ends up needing an API more like the document constructor methods, or it may be that some API is related so tightly to an element that we actually should hang it off the element and not one of the global singleton objects. It also depends a lot on the security model we want to use. If it turns out that we want a security model based on the user dragging and dropping a permission onto the page, maybe we need to hang the API off a drag-and- drop event's Event object. It also depends on the locking model we want to use, since that affects whether the API will be visible on Workers, which affects whether we should put the API on the Navigator object or the global scope, or whether to be inconsistent across both. In conclusion, I think that where the API is exposed is probably the last question that can be answered. We first need to determine what the API's security model is, what it's locking model is, what it's threading model is, what the API itself is, and so on. Then, the question of where to put the API mostly solves itself. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 7 October 2009 16:18:36 UTC