See also: IRC log
<trackbot> Date: 09 December 2009
<scribe> Scribenick: ilkka
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0155.html
fjh: any additions to agenda?
... lets cancel calls during holiday period
<fjh> minutes
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0154.html
RESOLUTION: Calls are cancelled on 23rd and 30th of December
<dom> December 2 proposed minutes
<fjh> trust
RESOLUTION: minutes from 2nd of December are approved
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0153.html
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
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
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-minutes.html#action01]
<trackbot> Created ACTION-73 - Draft a response TAG issue on privacy and policy [on Frederick Hirsch - due 2009-12-16].
darobin: I would like to ask editors of each draft to mail list of current issues
richt: small tweaks this week
... in contacts API
... It will still take some time to be able to upload first version Calendar API
<darobin> http://www.w3.org/mid/CC26A8D2-49CF-4137-8ABC-08D18FD921A0@berjon.com
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
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-minutes.html#action02]
<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
<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
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/
<dom> s/3986/3986/ RFC 3986 uri scheme
<tlr> here's the I-D I had in mind
<tlr> SMS URI scheme (proposed)
<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 .
marcin: I'll comment the draft when it's available
<dom> Systems Info & Events API editors draft
<dom> Proposed core interface for systems info, with get, set, and watch
maxf: get(), set() and watch() are the core funtions of the API
<dom> Discussion on units, value ranges for SysInfo
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 > Directory
<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 structures)
<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 http://dev.opera.com/articles/view/file-i-o-api-for-widgets/
<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 list
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]
<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