# Device APIs and Policy Working Group Teleconference

## 13 Jan 2010

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Robin_Berjon, Marco_Marengo, Dzung_Tran, Paddy_Byers,
Anssi_Kostiainen, Ilkka_Oksanen, Wonsuk_Lee, Dominique_Hazael-Massieux,
Claes_Nilsson, Richard_Tibbett, David_Rogers, Niklas_Widell, Marcin_Hanclik,
Suresh_Chitturi

Regrets

    John_Morris, Laura_Arribas, Dzung, Tran, Max, Froumentin

Chair

    Frederick_Hirsch, Robin_Berjon

Scribe

    paddy

## Contents

  * [Topics][5]

    1. [approval of minutes from 16 January][6]

    2. [Editorial update][7]

    3. [Policy][8]

    4. [API segment][9]

  * [Summary of Action Items][10]

* * *

<trackbot> Date: 13 January 2010

<Dzung_Tran> Regrets, I can only be on for 40mins today.

<scribe> ScribeNick: paddy

### approval of minutes from 16 January

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/att-0036/minutes-2010-01-06.html][11]

**RESOLUTION: minutes from 6 January are approved**

### Editorial update

fjh: any editors got any updates?

### Policy

fjh: sent message to TAG as discussed

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0041.html][12]

fjh: TAG acknowledged it and some discussion on list

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0067.html][13]

<dom> [Noah's response suggesting defining extensibility points for
privacy][14]

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0086.html][14] (

fjh: Noah suggested using "extensibility point" for privacy

... could allow different means of passing privacy information as a general
direction

... anyone any thoughts on this?

... Next step is to get into more detail, define use cases etc

... will leave this discussion to list

<fjh> Virtual web services

fjh: Other topic is virtual web services and there has been some discussion of
this on list

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0061.html][15]

fjh: I thought the approach suggesting using OAuth or other web-based
authentication mechanisms

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0068.html][16]

darobin: I thought OAuth was mentioned as something used on web generally, not
necessarily solution for local case

... I don't think Mark was proposing this for the local case

<dom> [John Kemp's early work on JavaScript using HTTP-like APIs][17]

fjh: richt asked whether or not it is necessary to actually run a web server

... I think the answer was no, there are alternative implementations

... I don't have a clear picture of what's being proposed

... darobin do you have a better understanding?

darobin: I think the idea was to provide the same functionality as a normal
API but exposed via XHR or similar

... like using a RESTful service, except that it's local

... happy to take on an action to flesh out what Mark said so it can be
discussed in more detail

fjh: wanted to be explicit that it is different from defining a JS API

<darobin> **ACTION:** Robin to flesh out Mark's device as local web service
proposal, using a Geo-based example [recorded in [http://www.w3.org/2010/01/13
-dap-minutes.html#action01][18]]

<trackbot> Created ACTION-81 - Flesh out Mark's device as local web service
proposal, using a Geo-based example [on Robin Berjon - due 2010-01-20].

fjh: I don't think it removes the requirement to define a policy framework
(question)

... want to be clear on how much we are proposing changing what is already
being discussed

<dom> [any objection to me raising an issue to match that discussion?]

darobin: will try to address as much as possible by fleshing out an example

fjh: any further coomments on this?

suresh: my initial reaction is that there are various things to discuss such
as what does it mean to the approach we took so far

... is it truly that all the functionality we are interested in can be
abstracted as a web service

... does it have an implication on how a Web Runtime is designed to operate?

... I think we need to understand the implications in a lot more depth before
we can know how to take it forward

... if we are in a situation in which this model only addresses a subset of
APIs in our charter, then will we end up with multiple approaches?

... I think we have to be very careful

<Zakim> dom, you wanted to suggest creating an issue and to note that
Firefox's geolocation API implementation is backed by a... Web service (last I
checked)

fjh: agree

dom: we should definitely create an issue to document the outcome of the
discussion

<darobin> ISSUE: Investigation around Virtual Web Devices

<trackbot> Created ISSUE-66 - Investigation around Virtual Web Devices ;
please complete additional details at
[http://www.w3.org/2009/dap/track/issues/66/edit][19] .

dom: second point is that from memory the Firefox implementation of
geolocation is based on a web service

... that's interesting in relation to this proposal

<richt> for the future I think web services = RESTful web apis

dom: ie it is a RESTful server (internally making GET requests and getting
geolocation data back)

darobin: entered action and issue already

<Zakim> Frederick_Hirsch, you wanted to ask about timeline

fjh: what is the timeline for this analysis?

we want to do this issue investigation but don't want to stall existing work

scribe: so what is our timeline on this?

darobin: share concern, so the intent is that this investigation will take 1-2
weeks

... a few days to write up, 10 days or so discussion

... at that point at least we can decide whether or not it merits deeper
investigation

<richt> to record my view, I think XHR is one implementation option for the
current JS API but that does not disallow other methods of implementation

fjh: anything else to discuss on policy?

<marcin> NAP: [http://lists.w3.org/Archives/Public/public-device-
apis/2009Oct/0092.html][20]

### API segment

darobin: first item is whether or not we agree to publish contacts as FPWD

... no objections to CFP last week

<dom> [CfC for publishing contacts as FPWD][21]

darobin: so are there any objections here?

**RESOLUTION: publish contacts as FPWD**

richt: although no objections, there are some updates pending

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan0083.html][22]

richt: do we publish as-is, or fix editorial issues first?

darobin: aren't they just minor?

richt: mostly minor

<Zakim> richt, you wanted to comment on outstanding editorial updates

darobin: why not fix minor issues first and then publish in next few days

fjh: was wondering about status of editorial comments, we should do the non-
controversial ones

richt: edits in progress but not uploaded yet

... attribute naming etc can be worked on after FPWD

dom: should I be waiting for signal from richt to transition to FPWD?

<fhirsch> Publications only happen on Tuesdays and Thursdays, correct

richt: I will send update over next few days, and then it will transition to
FPWD

don: I don't think there is any problem, no need to wait for next week's call

... but when do I know when the doc is ready?

<dom> **ACTION:** Dom to request transition of Contacts API as First Public
Working Draft when pinged by Robin [recorded in [http://www.w3.org/2010/01/13
-dap-minutes.html#action02][23]]

<trackbot> Created ACTION-82 - Request transition of Contacts API as First
Public Working Draft when pinged by Robin [on Dominique Hazaël-Massieux - due
2010-01-20].

darobin: I will work with richt on ReSpec issues etc and will ping dom when
done

<darobin> **ACTION:** Robin to ping Dom when Contacts FPWD is ready [recorded
in [http://www.w3.org/2010/01/13-dap-minutes.html#action03][24]]

<trackbot> Created ACTION-83 - Ping Dom when Contacts FPWD is ready [on Robin
Berjon - due 2010-01-20].

darobin: next topic is encouraging people to discuss capture API

<darobin> -< [http://www.w3.org/mid/6B36E0FB-
64A7-4E81-8639-67DB7FCDD7E3@robineko.com][25]

<fhirsch> action-74?

<trackbot> ACTION-74 -- Robin Berjon to send an email to list summarising the
options for <input> or not in Capture -- due 2009-12-16 -- CLOSED

<trackbot> [http://www.w3.org/2009/dap/track/actions/74][26]

darobin: to summarise, there has been a debate about using <input>, new API,
<device> proposal etc

<Dzung_Tran> Should we keep the capture API simple for version 1.0 or extended
to cover some advanced use cases

darobin: so a bit of a topic that's been all over the place

... so have come up with a rough proposal for 3 docs:

... 1) simple capture, not embedded

... 2) embeded viewfinder use case

... 3) streaming use case

... encourage people to jump into the thread and comment

... are there any comments now?

dom: I guess this proposal is that current proposal for capture is moot?

darobin: not completely, but it would need to be changed a lot?

dom: where would it fit in your 3 docs?

darobin: probably in the second doc, some aspects would be relevant such as
start, stop etc, except architected differently

... next topic is "where does it all hang off of?"

... most list discussion was in favour of option (1)

... to clarify, this was the one with navigator.device.<api>.<method>

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

<AnssiK> I'm questioning whether device is something we're happy with, instead
of service or something else

darobin: any objections to (1)?

richt: agree with (1)

... but proposed using a name different from "device"

... would prefer to rename to something more generic

... sent email to the list to that effect

<dom> ISSUE-44?

<trackbot> ISSUE-44 -- What do APIs hang off of? -- RAISED

<trackbot> [http://www.w3.org/2009/dap/track/issues/44][27]

<Suresh> Naming discussion is not easy:-)

darobin: saw email, wary of getting into unwelcome discussion of irrelevant
and arbitrary issues

... we can split into two separate decisions

... 1) do we resolve to go with (1), irrespective of the name

<marcin> FWIF: navigator.service.* could handle device and network APIs

darobin: 2) what the property name is

<dom> window.navigator.universe-and-everything

<drogersuk> +1 on option 1

<Suresh> deviceService?

darobin: does anyone object to resolution to go with (1)?

<drogersuk> (assuming option 1 was option 1 from the email)

**RESOLUTION: to go with option (1) for "where does it all hang off of?" but
without a decision yet on the specific property name**

<darobin> 1. Service object, simple method, inside device e.g.
navigator.device.dahut.graze()

darobin: will raise an issue for naming of "device" part or do people not want
to get into discussion?

marcin: need a resolution as much as possible

<AnssiK> I'd prefer a short and simple name, thus prefer e.g. service over
deviceService

marcin: agreement on something is more important on what the actual name uis

<richt> RE: naming, my proposal (still option 1) is:
navigator.service.dahut.graze()

darobin: will raise an issue that can be resolved next week

... ok?

<darobin> ISSUE: in navigator.device, should "device" be "service" or
something else?

<trackbot> Created ISSUE-67 - In navigator.device, should "device" be
"service" or something else? ; please complete additional details at
[http://www.w3.org/2009/dap/track/issues/67/edit][28] .

darobin: next topic is Max' action-80 on sys info but lets defer since Max is
not here

<dom> close ISSUE-44

<trackbot> ISSUE-44 What do APIs hang off of? closed

darobin: so is there anything else anyone wishes to discuss?

<richt> thanks, bye

darobin: ajourned

<marcin> thanks & bye

<nwidell> quit

<fhirsch> y

## Summary of Action Items

**[NEW]** **ACTION:** Dom to request transition of Contacts API as First
Public Working Draft when pinged by Robin [recorded in
[http://www.w3.org/2010/01/13-dap-minutes.html#action02][23]]

**[NEW]** **ACTION:** Robin to flesh out Mark's device as local web service
proposal, using a Geo-based example [recorded in [http://www.w3.org/2010/01/13
-dap-minutes.html#action01][18]]

**[NEW]** **ACTION:** Robin to ping Dom when Contacts FPWD is ready [recorded
in [http://www.w3.org/2010/01/13-dap-minutes.html#action03][24]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][29] version 1.135 ([CVS
log][30])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0092.html

   [4]: http://www.w3.org/2010/01/13-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #ActionSummary

   [11]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/att-0036/minutes-2010-01-06.html

   [12]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0041.html

   [13]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0067.html

   [14]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0086.html

   [15]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0061.html

   [16]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0068.html

   [17]: http://www.w3.org/2001/tag/2009/09/apis-on-the-web.html

   [18]: http://www.w3.org/2010/01/13-dap-minutes.html#action01

   [19]: http://www.w3.org/2009/dap/track/issues/66/edit

   [20]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Oct/0092.html

   [21]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0038.html

   [22]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan0083.html

   [23]: http://www.w3.org/2010/01/13-dap-minutes.html#action02

   [24]: http://www.w3.org/2010/01/13-dap-minutes.html#action03

   [25]: http://www.w3.org/mid/6B36E0FB-
64A7-4E81-8639-67DB7FCDD7E3@robineko.com

   [26]: http://www.w3.org/2009/dap/track/actions/74

   [27]: http://www.w3.org/2009/dap/track/issues/44

   [28]: http://www.w3.org/2009/dap/track/issues/67/edit

   [29]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [30]: http://dev.w3.org/cvsweb/2002/scribe/