W3C
Device APIs and Policy Working Group Teleconference
21 Jul 2011
Agenda
See also: IRC log
Attendees
Present
Ernesto_Jimenez, SungOk_You, Francois_Daoust, Robin_Berjon,
Frederick_Hirsch, Josh_Soref, Laszlo_Gombos, Kihong_Kwon,
Sullivan_Bryan, Kyung-Tak_Lee, Wonsuk_Lee, Jerome_Giraud,
Youngsun_Ryu, Ingmar_Kliche, Soonbo_Han, Wang_Johnson, Cecile_Marc
Regrets
Chair
Robin_Berjon, Frederick_Hirsch
Scribe
Josh_Soref
Contents
* Topics <#agenda>
1. Continued review of deliverables in draft Charter (rechartered)
<#item01>
2. Review of APIs that are not making progress <#item02>
3. HTTP-based APIs (based on WebKit feedback) <#item03>
4. Issue Review <#item04>
5. Action Review <#item05>
6. AoB <#item06>
* Summary of Action Items <#ActionSummary>
------------------------------------------------------------------------
Date: 21 July 2011
trackbot, start telecon
Meeting: Device APIs and Policy Working Group Teleconference
Date: 21 July 2011
http://www.w3.org/2011/07/DeviceAPICharter
ScribeNick: ingmar
Continued review of deliverables in draft Charter (rechartered)
discussion of what should be exposed to application and what
should not, with example of reading audio volume
I don't think that the Application needs to know anything
about Audio Levels
If it wants to show or have the option of showing Captions,
it should just do so
Anything that is typical of user behavior, e.g. turning off data
usage when roaming, does not need to be an API.
[charter-item] An API to read the current audio volume
level of a device
fjh: I hear consensus that the volume read API might be another charter
item which we will not work on
http://w3c-test.org/dap/proposals/request-feature/
fjh: introducer is on our list of things to do
... regarding privacy there are different rules in US/Canada and the EU,
we might need to look at this
robin: the charter defines the bounderies for the IPRs, it does not
oblige to work on a specific deliverable
Review of APIs that are not making progress
Gallery, http://dev.w3.org/2009/dap/gallery/
wonsuk: had an action item to review the gallery API
... need to do elaborate on use cases and requirements
... will provide input for the use cases and requirements section until
end of August
robin: it will be interesting to look at Gallery API on how it could
work with the HTTP approach
ACTION-216?
ACTION-216 -- WonSuk Lee to reformulate gallery API to look
like contacts API -- due 2010-07-21 -- OPEN
http://www.w3.org/2009/dap/track/actions/216
ACTION-368?
ACTION-368 -- WonSuk Lee to collect and summarize current use
cases for Gallery API and includes a draft doc -- due 2011-03-23 -- OPEN
http://www.w3.org/2009/dap/track/actions/368
ACTION-314?
ACTION-314 -- Anssi Kostiainen to react on media gallery use
cases -- due 2010-12-15 -- OPEN
http://www.w3.org/2009/dap/track/actions/314
aCTION-216 closed
ACTION-216 Reformulate gallery API to look like contacts API
closed
wonsuk: will work on ACTION-368 until end of August
ACTION-216: first need to review use cases and requirements, see
ACTION-368, then decide on next steps
ACTION-216 Reformulate gallery API to look like contacts API
notes added
fjh: there was a decision at the last TPAC to kill AppLauncher, we
should remove it from the DAP page
http://dev.w3.org/2009/dap/privacy-rulesets/
HTTP-based APIs (based on WebKit feedback)
robin: we received feedback that some of the APIs we designed might be
candidates for HTTP based APIs.
... we discussed this at least a year ago and didn't reach consensus on
a generic approach
Josh_Soref: it should be relatively straight forward to do a limited
binding for HTTP
http://www.w3.org/TR/WebIDL/
bryan: we should have a short discussion on the rationale
http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0061.html
Also
http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0083.html
also related -
https://lists.webkit.org/pipermail/webkit-dev/2011-July/017621.html
robin: if we would not define an API we would exclude a lot of services
(as the browser would only have integration of the local contacts and
probably a small list of HTTP based data sources)
bryan: points out that JS libraries could be used to access different
HTTP based data sources
Josh_Soref: accessing the datasources using JS has security implications
bryan: we started to develop an API for local data sources such as
contacts and now discussing a generic API for network based data
sources. This is a change in scope.
two models - direct access to local or web based providers, vs all
access mediated by local that then syncs with others as needed
bryan: makes the point that we started to do simple things for local
services, we should keep things simple and not make it more complex by
involving network based services
Josh_Soref: a network based API could be valuable if the browsers use
e.g. network based access to the local contact database, i.e. the local
database would be handled in the same way as a network based data source
robin: will start to write a first WebIDL mapping and Josh will help and
review
fjh: what does it mean for the contacts spec? Do we need to change
something?
Josh_Soref: we might need to add some fields
discussion - if we move away from javascript + idl approach then
idl would only serve as developer documentation, code directly written
to access web info, no tool for pre-processing?
this suggests that this approach would require something like web
introducer to achieve complete api, including security etc?
discussion as to whether this is actually simpler for developer
I am concerned that we are making many assumptions in this
assumption about what the browser/ua will do yet if that is not
specified it may not occur.
This could be an issue for privacy, user consent etc
How can we require implementation of both web introducer and a
contacts spec in combination - a conformance requirement document?
Josh_Soref: want the UA to allow the user to synthesize a contact
instead of only taking it from existing data sources
robin: synthesizing contacts is an implementation detail
[ I provided the example of me going to a street fair and
being asked to drop in a card into a Bowl for a contest ]
[ I could take my own business card from my wallet, or some
other card I collected, or I could write down some items onto a piece of
paper and drop that in. ]
interface changes and performance concerns?
[ I could even write out some items from an existing card,
or cross items out from a card ]
synthesized contact = returning portion of information from
contact, effectively creating a virtual contact
robin - performance issue could be naive implementation, using
HTTP locally with overhead etc.
ISSUE: how would feature discovery work for REST APIs
Created ISSUE-118 - How would feature discovery work for REST
APIs ; please complete additional details at
http://www.w3.org/2009/dap/track/issues/118/edit .
For a URL-based approach, browser processing (e.g. what is
returned in XHR response) would need to be clearly defined
How a URL-based approach (which would appear to be directly
usable by developers) would work with existing auth scheme such as OAuth
would need to be addressed in the spec.
Josh_Soref, you wanted to respond to fjh to explain that the
http approach means less work for Browser vendors which increases
likelyhood of them implementing
fjh: the HTTP approach would add more complexity on the definition of
the API
With a URL-based approach, it would be more likely that
developers would make errors in creating the URLs - this is the same
issue as using MIME type attributes to define video capture API options.
We would have to use caution to avoid duplicating similar
RESTful API work, e.g. the OMA/OneAPI APIs.
https://github.com/andreasgal/dom.js/blob/master/tools/idl2domjs
-> idl2js
bryan - can you drop in a link for OneAPI (for contacts)
fjh: the discussion would benefit from an example, we need to think
about security, privacy, discovery
in walking through the example
ernesto_jimenez, you wanted to ask josh for clarification on the
HTTP approach he has in mind
Overall there seems to be little difference in the expected
implementation cost.
Do we expect other groups to move in this direction as well,
e.g. why doesn't the File API use the URL approach? What about IndexedDB
etc?
good question - how is a remote database handled?
Do we expect a general move away from both markup and Javascript
APIs? Why do we need the