RE: What does it all hang off of?

I agree to starting with "device".
DAP is about device API, so we have the basic initial match of the intentions and results, and it is all clean and natural as of today.

On the other hand, I wonder what the term "device API" means.
At present, we want to access the functionality that historically has been implementated "natively", in C/C++ or in Java.
In the near future we will experience those functionalities beind developed fully in JavaScript, e.g. contacts, PIM  or mail (gmail) widget.
Then the given functionality will be probably realisable with HTML5 cross-document / cross-widget messaging.

Thanks,
Marcin
________________________________________
From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Stewart Brodie [stewart.brodie@antplc.com]
Sent: Tuesday, October 06, 2009 6:53 PM
To: public-device-apis@w3.org
Subject: Re: What does it all hang off of?

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


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Tuesday, 6 October 2009 20:35:48 UTC