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

Re: Hanging the APIs off navigator.device

From: Stewart Brodie <stewart.brodie@antplc.com>
Date: Thu, 7 Jan 2010 17:09:03 +0000
To: <public-device-apis@w3.org>
Message-ID: <54d4108250a8256bc06f74e147a56eea321bb86b@localhost>
Stewart Brodie <stewart.brodie@antplc.com> wrote:

> Suresh Chitturi <schitturi@rim.com> wrote:
> > Hi Robin, all,
> > 
> > I am in favor of 1).
> > It is distinct, elegant, zero risk for conflict and "device" interface
> > is something we can take ownership of without much involvement from HTML
> > WG.
> I also think (1) is best.

To expand a little on that, as requested by Robin in a later message, that's
because I agree with all the reasons Suresh stated.  In more detail:

[for reference]
> > 1. navigator.device.dahut.graze()
> > 2. navigator.device.dahutGraze()
> > 3. navigator.device.graze()
> > 4. navigator.dahut.graze()

I consider option 4 to be the worst option of all.  Options 1 and 4 are
actually the same except for the navigator pollution issue, but I think that
that would be a serious mistake, for no good reason. I've not seen any
convincing arguments for 4 that don't rely on hope that it doesn't cause
problems.  Are we *trying* to create conflicts with existing content?  Yes,
I have seen content that stashes things in navigator.  Is it likely to
clash?  Who knows - and that's the problem with it.  I do not think that
polluting an existing object with a large number of new properties (and I am
sure it will grow over time) is a good idea.  It's not like we're not trying
to specify this stuff retrospectively - there is an opportunity to do things
properly and cleanly rather than try to bodge it in.

Option 3 has similar problems to option 4.  It's asking to create clashes in
the 'device' object, but at least it doesn't pollute navigator.

IMHO, option 2 is simply ugly - do you really want to have to use long names
for everything?  You're going to end up with an awful lot of objects in

Option 1 is clean, simple to understand, and easy to use.  Each device API
can develop its own, standalone API specification without worrying about
conflicting with others (c.f. #3).  The names are meaningful (c.f. #2).
Existing objects are not polluted (c.f. #4).  The only potential name
clashes are with the API name itself - which the device API group can
control.  Option 1 also offers easier test suite development and
implementation testing, with fewer inter-dependencies.  Defining, checking
and verifying permissions should be much simpler this way too.

I believe that option 1 offers more advantages to content authors as well.
You end up with one object that implements an interface and nothing else.
You'll have a prototype object, which makes customisation easier too.
Furthermore, I think it will be easier for libraries to provide dummy
implementations of missing APIs - they can simply create an object and stash
it in navigator.devices if the browser doesn't support that particular API,
which should ease introduction of content that uses these new APIs.

That is why I believe option 1 is the best.

Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited
Received on Thursday, 7 January 2010 17:09:39 UTC

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