W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

Draft minutes 2009-12-09

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 9 Dec 2009 11:06:46 -0500
Message-Id: <19C5D988-25F7-4AFF-8435-C9FB824B7591@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Draft minutes from today's call, html below.

# Device APIs and Policy Working Group Teleconference

## 09 Dec 2009


See also: [IRC log][4]

## Attendees


    Dzung_Tran, Marco_Marengo, Frederick_Hirsch, Anssi_Kostiainen,
Niklas_Widell, Ilkka, Oksanen, Marcin_Hanclik, Robin_Berjon, Laura_Arribas,
Dominique_Hazael_Massieux, Thomas_Roessler, Max_Froumentin, Claes_Nilsson,
Wonsuk_Lee, John_Morris, David, Rogers


    Suresh_Chitturi, Arve


    Robin_Berjon, Frederick_Hirsch



## Contents

  * [Topics][5]

    1. [Welcome, agenda review, scribe selection][6]

    2. [Policy Segment][7]

    3. [API Segment][8]

  * [Summary of Action Items][9]

* * *

<trackbot> Date: 09 December 2009

<scribe> Scribenick: ilkka

### Welcome, agenda review, scribe selection

<fjh> [http://lists.w3.org/Archives/Public/public-device-

fjh: any additions to agenda?

... lets cancel calls during holiday period

<fjh> minutes

<fjh> [http://lists.w3.org/Archives/Public/public-device-

**RESOLUTION: Calls are cancelled on 23rd and 30th of December**

<dom> [December 2 proposed minutes][11]

<fjh> trust

**RESOLUTION: minutes from 2nd of December are approved**

<fjh> [http://lists.w3.org/Archives/Public/public-device-

### Policy Segment

fjh: differences between Nokia and BONDI policy frameworks are described in
the above mail

<dom> ACTION-38?

<trackbot> ACTION-38 -- Claes Nilsson to should issue recommendation on the
granularity of the security system -- due 2009-11-09 -- OPEN

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

Claes: I have action from Santa Clara meeting to provide input, will happen in
one week

fjh: Laura, do you anything to add to requirements

<fjh> Adding trust and use cases to requirements

<fjh> TAG and Policy

<fjh> [TAG issue on privacy and policy][14]

Laura_Arribas: will follow up soon

fjh: this is useful information, but not sure yet how to respond

<scribe> **ACTION:** frederick to draft a response TAG issue on privacy and
policy [recorded in [http://www.w3.org/2009/12/09-dap-

<trackbot> Created ACTION-73 - Draft a response TAG issue on privacy and
policy [on Frederick Hirsch - due 2009-12-16].

### API Segment

darobin: I would like to ask editors of each draft to mail list of current

richt: small tweaks this week

... in contacts API

... It will still take some time to be able to upload first version Calendar

<darobin> [http://www.w3.org/mid/CC26A8D2-49CF-4137-8ABC-

darobin: File system & file writer API: updated version will be available in
couple days. Feedback welcome.

<dom> [Next steps on Capture API?, from Dzung Tran][17]

Dzung_Tran: Capture API: discussion ongoing regarding how to build the UI

<darobin> **ACTION:** Robin to send an email to list summarising the options
for <input> or not in Capture [recorded in [http://www.w3.org/2009/12/09-dap-

<trackbot> Created ACTION-74 - Send an email to list summarising the options
for <input> or not in Capture [on Robin Berjon - due 2009-12-16].

<dom> [Progress report on Messaging from Niklas][19]

<dom> ACTION-65?

<trackbot> ACTION-65 -- Niklas Widell to provide an editors draft of the
Messaging API -- due 2009-12-02 -- OPEN

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

darobin: discussion ongoing whether to have programmatical API or <input>
based solution, or both

nwidell: first version of messaging API will be based on BONDI messaging API

s/BONDI messaging API/

<tlr> [][21]

<dom> s/3986/3986/ RFC 3986 uri scheme

<tlr> here's the I-D I had in mind

<tlr> [SMS URI scheme (proposed)][22]

<Zakim> maxf, you wanted to ask about the granularity of CVS commits

<tlr> RFC 3986 is the wrong reference for this

darobin: it better to have first version soon even if it's not well thought

maxf: when to do CVS commits?

darobin: always when the change makes sense

<AnssiK> +1 to release early, release often

<maxf> (of course, with git we won't have that problem anymore ;)

<tlr> +1 to commit early, commit very often

darobin: announce your changes because not all are subscribed to DAP-commits
mailing list

<AnssiK> shorter commit logs are easier to read and comment on

marcin: updated MMS related drafts exists

tlr: what are the requirements that can't be fulfilled using this URI scheme?

<dom> [maybe we can raise an issue about this point?]

<darobin> PROPOSED ISSUE: Make sure that uses cases for messaging don't
overlap with linking

<dom> PROPOSED ISSUE: what use cases justify using an API on top of the
existing URI schemes

<tlr> PROPOSED ISSUE: What messaging use cases cannot be fulfilled by existing
URI schemes (mailto, sms, mms)?

<darobin> ISSUE: What messaging use cases cannot be fulfilled by existing URI
schemes (mailto, sms, mms)?

<trackbot> Created ISSUE-54 - What messaging use cases cannot be fulfilled by
existing URI schemes (mailto, sms, mms)? ; please complete additional details
at [http://www.w3.org/2009/dap/track/issues/54/edit][23] .

marcin: I'll comment the draft when it's available

<dom> [Systems Info & Events API editors draft][24]

<dom> [Proposed core interface for systems info, with get, set, and watch][25]

maxf: get(), set() and watch() are the core funtions of the API

<dom> [Discussion on units, value ranges for SysInfo][26]

maxf: spec is written in an abstracted way

... e.g. temperature can be a value between 0 and 1

<Zakim> dom, you wanted to ask about roadmap

dom: we have now file writer api, how about full file system API?

<dom> [I think personally file writing is a more interesting priority than the
other operations]

dom: should file system API be a priority API?

Dave: file system API is a priority API

richt: full file system API for v1 is too big task

<tlr> for the record, "My Documents" is *not* a useful sandbox.

<tlr> it translates into "most of my interesting data"

<drogersuk> just an example - x sandbox

<drogersuk> underlying platform can always constrain to specific sandboxes for
specific purposes / applications / websites

<dom> what's the conclusion of this discussion?

<dom> ok, so the DAP homepage is already reflecting that, thanks

<darobin> PROPOSED RESOLUTION: all of File API is a priority, but Writing >

<richt> to clarify my point was that beyond file writer api, the next
acheivable spec would be a limited sandboxed file system api rather than
focussing on the a full file-system api for v1.

PROPOSED RESOLUTION: all of File API is a priority, inside the API, file
writer is a priority compared to other parts of the API

<richt> full file-system api = directories. A sandboxed model would not
provide any directory traversal o multi-level trees (sandboxes are flat

<arve> From the sideline, Opera has a sandboxed model for file system access

<arve> with the sandbox defined along "mountpoints"

<arve> not a flat structure, but honest-to-[deity] tree structures, path
traversal rules, and transparent traversal in to archives

<marcin> BONDI is still deciding about sandbox vs. full FS

<arve> I would like the WG to adopt this model, because it actually works

davidRogers: there is no concensus about the priority

<richt> interesting stuff arve. does Opera have anything to provide to DAP?

davidRogers: we are not yet ready to make a resolution

<arve> richt, dom, ilkka - see this

<arve> we could then argue the finer points of actually accessing files

<arve> but this is what we have implementation experience with

<tlr> q

darobin: no resolution on this call

<fjh> reminder - wg members should review the drafts, and make comments on the

davidRogers: file writer API is in conflict with BONDI proposal

<fjh> Issues should also be raised in tracker and discussed on the list

<dom> I think there are 3 topics: 1) File reader might need additional work
from DAP; 2) that additional work needs to be a priority over File writing; 3)
File writing is a priority over directory mangement

<dom> I think we can agree on 3); I hadn't heard about 1) and 2) before

<dom> **ACTION:** David to send OMTP position on the file API organization
[recorded in [http://www.w3.org/2009/12/09-dap-minutes.html#action03][28]]

<trackbot> Created ACTION-75 - Send OMTP position on the file API organization
[on David Rogers - due 2009-12-16].

<dom> (I think Richard should bring his ideas to the list — we're unlikely to
be able to digest a detailed proposal on the phone :)

<tlr> +1 to dom

richt: in priority-wise: file writing > sand boxing > directory management

<richt> Ilkka, that is my proposal. Thanks. That is a better way of looking at
how to proceed.

meeting adjourned

<darobin> thanks ilkka

## Summary of Action Items

**[NEW]** **ACTION:** David to send OMTP position on the file API organization
[recorded in [http://www.w3.org/2009/12/09-dap-minutes.html#action03][28]]

**[NEW]** **ACTION:** frederick to draft a response TAG issue on privacy and
policy [recorded in [http://www.w3.org/2009/12/09-dap-

**[NEW]** **ACTION:** Robin to send an email to list summarising the options
for <input> or not in Capture [recorded in [http://www.w3.org/2009/12/09-dap-

[End of minutes]

* * *

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

$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-

   [4]: http://www.w3.org/2009/12/09-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #ActionSummary

   [10]: http://lists.w3.org/Archives/Public/public-device-

   [11]: http://lists.w3.org/Archives/Public/public-device-

   [12]: http://lists.w3.org/Archives/Public/public-device-

   [13]: http://www.w3.org/2009/dap/track/actions/38

   [14]: http://lists.w3.org/Archives/Public/public-device-

   [15]: http://www.w3.org/2009/12/09-dap-minutes.html#action01

   [16]: http://www.w3.org/mid/CC26A8D2-49CF-4137-8ABC-08D18FD921A0@berjon.com

   [17]: http://lists.w3.org/Archives/Public/public-device-

   [18]: http://www.w3.org/2009/12/09-dap-minutes.html#action02

   [19]: http://lists.w3.org/Archives/Public/public-device-

   [20]: http://www.w3.org/2009/dap/track/actions/65

   [21]: http://tools.ietf.org/html/rfc3986

   [22]: http://tools.ietf.org/html/draft-wilde-sms-uri-20

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

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

   [25]: http://dev.w3.org/2009/dap/system-info/#the-system-interface

   [26]: http://lists.w3.org/Archives/Public/public-device-

   [27]: http://dev.opera.com/articles/view/file-i-o-api-for-widgets/

   [28]: http://www.w3.org/2009/12/09-dap-minutes.html#action03

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

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

regards, Frederick

Frederick Hirsch

Received on Wednesday, 9 December 2009 16:07:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:03 GMT