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

RE: ISSUE-67: Naming of "device"

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Thu, 14 Jan 2010 23:48:56 +0100
To: Doug Turner <w3c@dougt.org>
CC: "richard.tibbett@orange-ftgroup.com" <richard.tibbett@orange-ftgroup.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C289432A292@OBEEX01.obe.access-company.com>
Hi Doug,

Geo WG created one API, i.e. one module, although they do not use WebIDL's "module" in their doc, therefore I am not sure whether it is fully representative.

Some comments from BONDI experience [1]:
1. BONDI uses bondi.interface.method (interface and method in WebIDL sense). Therefore it is actually what you propose (up to the module vs. interface, but I assume we are aligned).
2. Although in BONDI we work on modules, WebIDL's module semantics is used only for grouping and for linking the security model with the APIs (by e.g. providing the naming convention). Its name does not appear when writing JS code (apart from URI identifiers).
3. "bondi." was clean, it did not exist before BONDI started using it. It seems to be different situation than with "navigator." where we have legacy stuff.
4. In BONDI the inter-module dependencies are a topic, i.e. when you want to use some interfaces from one module in another (related to the security model and policy).

To sum up:
I think I will agree to anything the comes out from the cold calculation of votes :)

Thanks,
Marcin

[1] http://bondi01.obe.access-company.com/1_1_4627_130/webidl_clickable.html
________________________________________
From: Doug Turner [w3c@dougt.org]
Sent: Thursday, January 14, 2010 11:24 PM
To: Marcin Hanclik
Cc: richard.tibbett@orange-ftgroup.com; public-device-apis@w3.org
Subject: Re: ISSUE-67: Naming of "device"

Marcin,

Thank you for the response.  I understand where some in the group are coming from.

The W3C Geolocation WG selected:

navigator.<module>.method

Given this api has already been deployed to millions of users, I worry about doing something differently in this WG.  We did not add a .device., .dap., or any other RSI word after navigator, and the world didn't fall apart.  I claim we do not need to invent a new object under navigator for any of the DAP work.

Doug


I am unsure if
On Jan 14, 2010, at 2:10 PM, Marcin Hanclik wrote:

> 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.
> navigator.dap.(module|interface).method
> 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.
>
> Thanks,
> Marcin
>
> [1] http://news.bbc.co.uk/2/hi/8306631.stm
> ________________________________________
> From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Doug Turner [w3c@dougt.org]
> Sent: Thursday, January 14, 2010 9:00 PM
> To: richard.tibbett@orange-ftgroup.com
> Cc: public-device-apis@w3.org
> 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?
>
> Thanks!
> Doug
>
>
>
> On Jan 14, 2010, at 9:54 AM, <richard.tibbett@orange-ftgroup.com> wrote:
>
>> Ah, referenced the wrong minutes:
>>
>> [2]
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0105.html
>> (13th Jan 2010)
>>
>>> -----Original Message-----
>>> From: TIBBETT Richard RD-ILAB-LON
>>> Sent: 14 January 2010 17:53
>>> To: 'Doug Turner'
>>> Cc: public-device-apis@w3.org 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 http://www.w3.org/2009/dap/track/resolutions
>>>
>>> [2]
>>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan
>>> /0036.html
>>>
>>>> -----Original Message-----
>>>> From: public-device-apis-request@w3.org
>>>> [mailto:public-device-apis-request@w3.org] On Behalf Of Doug Turner
>>>> Sent: 14 January 2010 16:49
>>>> To: Anssi Kostiainen
>>>> Cc: Robin Berjon; public-device-apis@w3.org 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 http://robineko.com/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>> *********************************
>> 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
>
> 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.


________________________________________

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 Thursday, 14 January 2010 22:49:36 UTC

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