Re: ISSUE-67: Naming of "device"

+1 to navigator.dap.*


----- Original Message -----
From: <>
To: Doug Turner <>; <>
Cc: <>
Sent: Thu Jan 14 17:10:11 2010
Subject: RE: ISSUE-67: Naming of "device"

Hi Doug,

I think it is about grouping.
navigator.device.(module|interface).method was intended for device APIs, so "device" made sense.
There is semantics behind that.

However, the discussions about allowing the APIs to be realized based on a webservice (locally within the device, smart card over http: or remotely), i.e. potentially decoupling them from the actual device, remove the association between the actual device and "navigator.device", IMHO.
Therefore I now assume that another name could be selected :(.

Taking into account Robin's RSI arguments, I think that api, ext would work (Tim Berners-Lee already apologized for slashes [1] :) ) .
service is very general and fits semantically, but it is simply longer.

The need to have something between navigator and (module|interface in WebIDL sense) seems to have resulted from having undocumented (in W3C sense) properties on navigator. The "grouping" principle solved this issue by adding just one new property (green, anti-pollution argument).

Another idea could be to have "dap", i.e.
simply in honor of the DAP WG :)
If there will be next WGs (in W3C or somewhere else), they could e.g. group their APIs under their group's name.


From: [] On Behalf Of Doug Turner []
Sent: Thursday, January 14, 2010 9:00 PM
Subject: Re: ISSUE-67: Naming of "device"

... people found it clearer, more extensible, less conflict with other
existing properties of navigator

Anyone care to elaborate? what conflicts are there today?  how is adding another object under navigator more extensible?


On Jan 14, 2010, at 9:54 AM, <> wrote:

> Ah, referenced the wrong minutes:
> [2]
> (13th Jan 2010)
>> -----Original Message-----
>> From: TIBBETT Richard RD-ILAB-LON
>> Sent: 14 January 2010 17:53
>> To: 'Doug Turner'
>> Cc: WG
>> Subject: RE: ISSUE-67: Naming of "device"
>> Hi Doug,
>> On the conf. call we resolved to go with 'Option 1:
>> navigator.device.dahut.graze()' [1].
>> Meeting minutes are available here [2].
>> Best Regards,
>> Richard
>> [1] 'Resolution #90' in
>> [2]
>> /0036.html
>>> -----Original Message-----
>>> From:
>>> [] On Behalf Of Doug Turner
>>> Sent: 14 January 2010 16:49
>>> To: Anssi Kostiainen
>>> Cc: Robin Berjon; WG
>>> Subject: Re: ISSUE-67: Naming of "device"
>>> My option isn't in the list, so I will state it plainly.
>> My position
>>> is that we use:
>>> navigator.<module>.<method>
>>> as
>>> 1) .device. offers no real namespace and it is extra characters to
>>> type
>>> 2) it fit in navigator.geolocation.*
>>> Widgets or other things that do not have a navigator object
>> can root
>>> these APIs under a different object (e.g.
>>> widget.<module>.method, or even <module>.method)
>>> By the way, the bike shed must be red.
>>> Doug Turner
>>> On Jan 14, 2010, at 6:13 AM, Anssi Kostiainen wrote:
>>>> api, ext, device, service
>>>> With tequila? Yes sir!
>>>> -Anssi
>>>> On 14.1.2010, at 16.02, ext John Kemp wrote:
>>>>> api, ext, device, service
>>>>> Are you inviting us for tequila too (in which case, I
>>> accept) Robin?
>>>>> ;)
>>>>> - johnk
>>>>> On Jan 14, 2010, at 8:41 AM, Robin Berjon wrote:
>>>>>> Hi all,
>>>>>> I am loth to open a naming debate, so as agreed on the
>>> call yesterday let's make it swift. I initially planned on
>> doing this
>>> on a Friday, but I won't be around tomorrow so today's the
>> new Friday.
>>>>>> We've resolved to use the
>>> navigator.device.<module>.<method> form yesterday (for APIs
>> where it
>>> makes sense, naturally). It's been suggested that "device"
>> isn't such
>>> a great name, and alternatives have been proposed.
>>>>>> The following alternative (including keeping things as
>>> they are) have been proposed:
>>>>>> device
>>>>>> service
>>>>>> api
>>>>>> ext
>>>>>> Since this is essentially a bike-shed decision, I've
>>> decided to use a variant of the Survivor decision process.
>>> The normal Survivor process is synchronous and therefore won't work
>>> well here. The variant is this: please vote with the list
>> of options
>>> above ordered from the one you *hate
>>> most* (and therefore want to see voted off the island) to
>> the one you
>>> hate least. The winner will be selected using a commonsensical
>>> ordering and tequila. Voting closes when I get to work
>> Monday morning;
>>> since this is a vote (albeit
>>> informal) we don't need to know what the reasoning behind your
>>> preference is (though you may include it, if it's entertaining
>>> enough).
>>>>>> My vote: api, ext, device, service.
>>>>>> --
>>>>>> Robin Berjon
>>>>>> robineko - hired gun, higher standards
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************


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

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.

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Thursday, 14 January 2010 23:00:26 UTC