- From: Stewart Brodie <stewart.brodie@antplc.com>
- Date: Tue, 6 Oct 2009 17:53:43 +0100
- To: <public-device-apis@w3.org>
Robin Berjon <robin@berjon.com> wrote: > 4) Use an object to provide access to all the device APIs: > > var mum = device.contacts.findOne({ nickname: "mum" }); > > I think the latter is the cleanest option. Specifying one such > extensible object is trivial, and would be a very short specification. > > Another option is to hang off of the navigator object just like > geolocation did — but that seems wrong (I'm not sure why it was chosen > there). I agree that that is cleanest and that dumping all the new interfaces into Navigator is wrong. When I needed to add several new separate APIs, I created a single property in Navigator that returned an object that provided access to lots of interfaces - similar to your suggestion. It has worked very well as a means of keeping things cleanly separated and has made it easier for us to document. This would mean you'd get at it by doing: var address_book = navigator.device.contacts; var mum_method_1 = navigator.device.contacts.findOne( "mum" ); var mum_method_2 = address_book.findOne( "mum" ); The main advantages of this are: you add just a single property to one existing object; that you do not pollute the global; available APIs become discoverable via object enumeration (i.e. ECMAScript's for-in); it's simple and short to specify. It might even simplify API security, perhaps? Each new device API would only be required to implement a mixin interface that adds a property to the NavigatorDevice object (or whatever you want to call the object 'device' is) that returns an object implementing the API concerned. At this early stage, would it be possible to modify Geolocation to fit with such a scheme - perhaps just making it available this way as well as directly as the it is at the moment? -- Stewart Brodie Software Engineer ANT Software Limited
Received on Tuesday, 6 October 2009 16:54:18 UTC