# Device APIs and Policy Working Group Teleconference

## 20 Jan 2010

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Robin_Berjon, Dzung_Tran, Anssi_Kostiainen,
Ilkka_Oksanen, Dominique_Hazael-Massieux, Marco_Marengo, Richard, Tibbett,
Niklas_Widell, Paddy_Byers, Claes_Nilsson, Brad_Lassey, Marcin_Hanclik,
Suresh_Chitturi

Regrets

    John_Morris

Chair

    Robin, Frederick

Scribe

    AnssiK

## Contents

  * [Topics][5]

    1. [Admin][6]

    2. [Minutes approval][7]

    3. [API Discussion][8]

    4. [How to handle Capture][9]

    5. [Sysinfo][10]

    6. [AOB][11]

    7. [Adjourn][12]

  * [Summary of Action Items][13]

* * *

<trackbot> Date: 20 January 2010

<darobin> we should install a rule that whoever joins last gets to scribe

<arve> we should get someone to donate voice recognition

<scribe> ScribeNick: AnssiK

### Admin

<fhirsch> Prague F2F logistics sent to list

darobin: no specifics on the Prague f2f logistics, see the DAP page for more
info, or ask Robin

### Minutes approval

**RESOLUTION: minutes from 13 Jan approved**

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

fh: Robin has sent a nice summary of REST approach to the ML

<darobin> [][15]

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

<fjh> my comments - [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0166.html][17]

<dom> ISSUE-66?

<trackbot> ISSUE-66 -- Investigation around Virtual Web Devices / REST-ful
oriented APIs -- OPEN

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

<dom> ACTION-81?

<trackbot> ACTION-81 -- Robin Berjon to flesh out Mark's device as local web
service proposal, using a Geo-based example -- due 2010-01-20 -- OPEN

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

darobin: Robin's doc discusses the advantages and issues with exposing local
data services as REST services instead as of APIs.

... an example use case for REST API discussed: contacts can be exposed by
services such as FB etc.

... Robin is asking for feedback on the ML

fh: do we need a specific JS library to hide the bare-metal XHR?

darobin: jQuery is just an example that could be used

... also noted jQuery is an open source library

fh: a special protocol is needed, a concern?

darobin: push use cases are a bit problematic in REST API

<arve> (for a dumb question)

fh: what were Steven's and John Kemp's proposals referred on the doc?

darobin: Steven's proposal not documented, was f2f

<fhirsch> suggestion from stephen to provide generic database like interface
to contacts etc

<dom> [that's one of the things Robin highlights in the document
[http://dev.w3.org/2009/dap/docs/virtual-ws.html#which-uri-to-expose][20]]

<dom> Arve: given the struggle we have been going through for registering the
widget: URI scheme, it looks like defining a new scheme for something that
would use as if it was HTTP is likely to be problematic

<arve> My question is one : If we are doing something _nearly_ like HTTP, why
shouldn't we just use HTTP in the first place, and require local web servers?

<arve> and wouldn't that actually require us to specify these APIs in a non-
rest way anyhow

<fhirsch> I think arve is saying we need javascript APIs as a base for an HTTP
REST interface anyway

<Zakim> richt, you wanted to discuss how the response data is defined (in
WebIDL?)

<arve> fhirsch, +1

<fjh> proposed action - arve to write up example of need for javascript API
even with HTTP REST interface

<dom> +1 on proposed **ACTION:**)

<arve> action accepted

<trackbot> Sorry, bad ACTION syntax

<darobin> **ACTION:** arve to detail his view on double-API specification for
LREST [recorded in [http://www.w3.org/2010/01/20-dap-
minutes.html#action01][21]]

<trackbot> Created ACTION-84 - Detail his view on double-API specification for
LREST [on Arve Bersvendsen - due 2010-01-27].

richt: response data format must be well-formatted

... could be JSON or XML, for example

darobin: let's focus on a one data exchance format

<Zakim> richt, you wanted to discuss how the response data is defined (in
WebIDL?) ...in not too much detail :-)

fh: we'll need to walk though the security considerations

... asking if BONDI has some related input

... does OAuth solve all out problems?

paddy: the topic was discussed in BONDI in its early stage

... and I can summarize the issues

<darobin> ACTION paddy to provide his thoughts on LREST based on experience
from BONDI's earlier discussions on the same

<trackbot> Sorry, amibiguous username (more than one match) - paddy

<trackbot> Try using a different identifier, such as family name or username
(eg. pbyers, pbyers2)

<darobin> ACTION pbyers2 to provide his thoughts on LREST based on experience
from BONDI's earlier discussions on the same

<trackbot> Created ACTION-85 - Provide his thoughts on LREST based on
experience from BONDI's earlier discussions on the same [on Paddy Byers - due
2010-01-27].

<fjh> ilkka notes benefit of remote access to apis via rest approach, but
without remote access will require additional implementation work vs
javascript approach

<fjh> need to distinguish remote access to device versus device accessing
local or remote services from device

<fjh> or do we

darobin: the thinking is that the same REST API could be used to access both
remote and local services

richt: the current JS API approach enables fallback to other conforming
implementation, e.g. if the local fails fall back to cloud

darobin: let's follow-up on the ML

<Suresh> sorry to be so late!

### API Discussion

darobin: contacts FPWD is in the pipeline i.e. out tomorrow

<dom> ACTION-82?

<trackbot> ACTION-82 -- Dominique Hazaël-Massieux to request transition of
Contacts API as First Public Working Draft when pinged by Robin -- due
2010-01-21 -- OPEN

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

darobin: Where does it all hang off of decision

... and the winner is: service (least hated option)

<dom> ISSUE-67?

<trackbot> ISSUE-67 -- In navigator.device, should "device" be "service" or
something else? -- OPEN

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

<Suresh> navigator.dap.*?

<tlr> I think it needs to be service.dap

dom: happy with the "service"

<darobin> PROPOSED RESOLUTION: go ahead with "service", document it in Core
Devices, and mark it as pending feedback from implementors

<Suresh> q

<arve> -1

<richt> we can always change later based on implementation feedback

<marcin> when is it to made final? at REC level of Core DEvices?

<marcin> fjh, navigator.service.*

Suresh: we have to describe if the implementation is local or remote

<marcin> darobin, thanks

<darobin> ACTION Robin to update Core Devices

<trackbot> Created ACTION-86 - Update Core Devices [on Robin Berjon - due
2010-01-27].

<richt> 'service' means 'requires interaction with an external entity -
device/web or otherwise'.

<Zakim> arve, you wanted to explain his objection

Suresh: just to make sure people do not misinterpret the term "service"

arve: "service" means different things to different people, in the Web context
it has always referred to a web service -- causes confusion

<maxf> brb

<tlr> ugh

arve: Opera Unite APIs also have a notion of a service, which is a traditional
web service

<fjh> arve argues that using service implies web services approach, not
necessarily agreed

<Suresh> or, I think something neutral would be better e.g. "dap"

darobin: general conflict with service?

arve: does not want to call File I/O or Geolocation a "service"

<darobin> PROPOSED RESOLUTION: call it "monkey"

<marcin> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0154.html][24]

tlr: if we continue to have strong feelings on the issue, perhaps we do not
need a common ns at all

<blassey> navigator++

<Suresh> I don't think we should be going back

<arve> navigator++

<maxf> navigator++

<darobin> PROPOSED RESOLUTION: just put stuff on navigator, if it breaks the
web we'll cross that bridge then

<tlr> do we have any such objects?

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

<richt> Consider this on an API by API basis? e.g. Sys info would probably
benefit from navigator.device (it is device only at all times) but contacts
and calendar benefits from navigator.service or navigator.resource (it is
abstract and can be linked to any external contact providing entity, web or
otherwise).

from John Kemp's mail: "My reasoning for having a group name (I prefer
'service') might be that if we were to create constants that might be relevant
to _all_ of the APIs then rather than place them in each individual API
object, we could put them into the "global" object. Do we have anything that
looks like it might fit?"

<darobin> PROPOSED RESOLUTION: decide nothing, leave each API duke it out on
its own

fjh: security and privacy mechanisms may benefit from a common ns, is this a
consideration?

<paddy> +1 for formal vote service vs device vs dap

Suresh: we shouldn't go back to navigator.foo

darobin: we may need to vote

<darobin> PROPOSED RESOLUTION: decide nothing, leave each API duke it out on
its own

<darobin> PROPOSED RESOLUTION: enforce nothing, leave each API duke it out on
its own

<fjh> +1 to taking to the list

<darobin> PROPOSED RESOLUTION: leave each API duke it out on its own

Suresh: would like to come to an agreement on the call

<fjh> my +1 was to try to get to an agreement on common space on list

<Suresh> +1

<arve> +1

darobin: everyone happy with the proposed resolution?

<darobin> RESOLUTION: leave each API duke it out on its own

<darobin> [][26]

### How to handle Capture

<Suresh> my +1 was the same as fredrick's +1 but no worries!

<dom> 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][27]

<dom> (actually Dzung did comment)

ilkka: a reasonable proposal, what's the split across L1, L2, L3

<dom> (+1 on v1 being level 1 and level2)

<ilkka> +1

darobin: v1 could be L1 and L2

ilkka: supports

... can think how to turn this into a spec

### Sysinfo

<dom> (I would like to hear progress reports (or lack thereof) on Messaging
and Calendar, if possible)

<darobin> [][28]

maxf: the spec exposes multiple devices for a given property

... e.g. for power, battery, AC

... the question is whether this level of detail is useful

... some people argued not good enough use cases to support such granularity

<maxf> [http://dev.w3.org/2009/dap/system-info/properties-simplified.png][29]

maxf: a simplified set of properties was suggested

... example: replaced n CPU loads with one, the same for power and others

<darobin> ACTION maxf to look at potential proc alignment (as a suggestion)

<trackbot> Created ACTION-87 - Look at potential proc alignment (as a
suggestion) [on Max Froumentin - due 2010-01-27].

<Suresh> back on the call!

<nwidell> (need to leave the call in a two minutes) Messaging: Rough draft of
SMS done (including comment on SMS URI).

darobin: any objections to publish FPWD?

maxf: can do the edits (simplification) in couple of days

<Zakim> richt, you wanted to talk about status update on Calendar API

richt: will do the edits by the end of this weeks

nwidell: a rough release of Messaging API perhaps out in the end of this week

darobin: Planning for the 25% point: where do we want to be by the F2F?

... should revisit the timelines on the DAP site

### AOB

(none)

### Adjourn

<darobin> thanks a lot AnssiK!

<darobin> as the first person to scribe twice you get extra beer

## Summary of Action Items

**[NEW]** **ACTION:** arve to detail his view on double-API specification for
LREST [recorded in [http://www.w3.org/2010/01/20-dap-
minutes.html#action01][21]]


[End of minutes]

* * *

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

$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/0160.html

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

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #ActionSummary

   [14]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/att-0105/minutes-2010-01-13.html

   [15]: http://dev.w3.org/2009/dap/docs/virtual-ws.html

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

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

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

   [19]: http://www.w3.org/2009/dap/track/actions/81

   [20]: http://dev.w3.org/2009/dap/docs/virtual-ws.html#which-uri-to-expose

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

   [22]: http://www.w3.org/2009/dap/track/actions/82

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

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

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

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

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

   [28]: http://dev.w3.org/2009/dap/system-info/

   [29]: http://dev.w3.org/2009/dap/system-info/properties-simplified.png

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

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