See also: IRC log
<trackbot> Date: 17 August 2011
<fjh> Chair: Frederick_Hirsch
<fjh> FPWD of "Web Application Privacy Best Practices" has been published, see http://www.w3.org/TR/2011/WD-app-privacy-bp-20110804/
<fjh> Call for participation, AR standards 24-25 October http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0017.html (Rob Manson)
<scribe> Scribe: JoshSoref
<fjh> F2F #6: 19-21 July 2011 (Paris)
<fjh> 19 July 2011 minutes (Day 1) http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/att-0088/minutes-2011-07-19.html
<fjh> 20 July 2011 minutes (Day 2) http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/att-0098/minutes-2011-07-20.html
<fjh> 21 July 2011 minutes (Day 3) http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/att-0100/minutes-2011-07-21.html
<fjh> proposed RESOLUTION: Minutes from 19-21 July 2011 (F2F) are approved
RESOLUTION: Minutes from 19-21 July 2011 (F2F) are approved
fjh: ISSUE-114
<fjh> ISSUE-114?
<trackbot> ISSUE-114 -- Battery spec should note relative ordering of battery low versus battery critical in terms of criticality -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/114
<fjh> ACTION-426?
<trackbot> ACTION-426 -- Robin Berjon to draft the proposed design of getting rid of battery{low,critical} and adding a field that indicates state=ok/low/critical -- due 2011-07-26 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/426
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0099.html
AnssiK: it's a sound proposal
... i can integrate it into the specificaiton after the call
... was this in the f2f?
fjh: no, it came after
AnssiK: it seems functionally equivalent to the previous one
... so it should work for me
dom: i haven't reviewed this in detail yet
... one concern i have is that
... would you still be able to register for only getting battery critical events?
... rather than all events?
fjh: it seems to limit the events
AnssiK: you'd have to register for the
... battery status events
... and ...
dom: that seems inefficient if all you care about is criticals
fjh: one of the arguments is that it isn't meaningful
... i think that was Josh's argument
[ it was ]
<fjh> ISSUE-113?
<trackbot> ISSUE-113 -- AddEventListener in Battery Status has side effects -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/113
<fjh> ISSUE-115?
<trackbot> ISSUE-115 -- Do you get the batterylow event when you're charging and cross that boundary? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/115
AnssiK: i looked at the side effects ISSUE-113 and GeoLocation WGs
... and there were two camps
... one side favored simplicity for the developer over architectural purity
... it seems that the GeoLocation discussion is closed and they are not giving us any guidance
... I've flagged the battery related emails
... and I'll send a summary with my intentions
<fjh> ACTION-435?
<trackbot> ACTION-435 -- Laszlo Gombos to update the Permissions draft based on f2f discussion and summary email from Robin in planning for FPWD -- due 2011-09-01 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/435
<fjh> ISSUE-109?
<trackbot> ISSUE-109 -- We need solid use cases for Feat Perms if it's going to fly -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/109
<fjh> ACTION-436?
<trackbot> ACTION-436 -- WonSuk Lee to provide an example for Permissions -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/436
wonsuk: there's some issues relating to
... feature permissions
... I need to talk to lgombos about it
... I will propose something to the list
fjh: we've had a bunch of use case proposals on the list
<fjh> Ambient, http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0103.html (Dzung Tran)
<fjh> Temperature, http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0104.html
<fjh> ACTION-439, Bryan http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0004.html
<fjh> Semantic Sensor Network XG Final Report http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0106.html
fjh: i'm not sure how we should pull the stuff together
<fjh> will pursue this on the list as those who contributed use cases not on call. Need someone to pull this material together.
<Dzung_Tran> BTW: I am working with JOSE from the WAC group on taking what we have in System Info for sensors and what WAC has for sensors and merge them
<richt> Dzung, could be of interest. What's the plan for the resulting spec?
<Dzung_Tran> I will publish a proposal for sensors API once JOSE and I believe it is ready
fjh: this isn't a followup
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0018.html
fjh: there was an additional message from richt about automated registration
... by integrating with discovery mechanisms
... there's another item which is related to EU project webinos
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0024.html
fjh: richt / Claes : could one of you introduce them?
richt: the current proposal is local network
... this message was about extending that to the whole web
... it's in many ways similar to web introducer
... but it's using an automated process and discovery
... reviews and feedback on the list would be great
... it will probably hit the spec in the next few weeks
fjh: Claes, can you talk about webinos / its javascript system?
Claes: I think it will be interesting for DAP to see the APIs we have defined in webinos
... especially in service discovery
... i tried to give a brief overview of these two apis in my mail
<fjh> Claes message related to both service discovery and sensors, see http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0024.html
Claes: i encourage everyone to read the input and give feedback
fjh: thank you, i think it will take people time to read your message and read the referenced apis
fjh: an EU project did an analysis of a number of W3C deliverables
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0006.html
fjh: and concluded there could be more coordination between them
[ which shocked no one ]
fjh: they mentioned our work specifically
<fjh> Device API specifications
<fjh> a. MediaCaptureAPI
<fjh> b. System Information API
<fjh> c. Permissions for Device API Access
<fjh> d. Device API Privacy Requirements
fjh: we're already reworking (a) and (b)
... they asked for things to be integrated across specs
... which is something we can't do in our WG
... dom: did you have something to say?
... do we need more time?
dom: yes, we need to look at it, we need more time, and ideally someone needs to take an action item
<fjh> ACTION: fjh to review security issue http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0006.html [recorded in http://www.w3.org/2011/08/17-dap-minutes.html#action01]
<trackbot> Created ACTION-446 - Review security issue http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0006.html [on Frederick Hirsch - due 2011-08-24].
<richt> RE: Network Info API. Anyone been following this bug? https://bugzilla.mozilla.org/show_bug.cgi?id=677166
JoshSoref: I'll take an action to speak to someone about that
<richt> thanks Josh
JoshSoref: I don't think that the proposals are a good direction
... I followed up with PhoneGap
... and i summarized my conversation with Brian to the list
<fjh> ACTION-438?
<trackbot> ACTION-438 -- Josh Soref to talk to Brian Leroux about the Netinfo API in PhoneGap to ask about uptake and feedback -- due 2011-07-27 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/438
JoshSoref: in short...
... the requirements involve three things:
1. handling the case when you're offline
<fjh> ACTION-438: see http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0022.html
<trackbot> ACTION-438 Talk to Brian Leroux about the Netinfo API in PhoneGap to ask about uptake and feedback notes added
2. dealing with evil networks which kill idle sockets
3. adapting to bandwidth constraints
<fjh> close ACTION-438
<trackbot> ACTION-438 Talk to Brian Leroux about the Netinfo API in PhoneGap to ask about uptake and feedback closed
JoshSoref: the problem is that there's no guarantee that the device will actually be right next to the weakest/evilest link
... in cases of laptops or tablets
... using wifi basestations which are re-sharing cellular connections
... the information that the browser could expose would lead applications to the wrong conclusion
... the right thing to do is to discover the constraints by doing what you need and reacting to failures
... or increasing load if you don't hit failures
<fjh> josh notes that applications need to respond intelligently to failures and this is out of the capability of browser, and such netinfo api would be either misleading or not helpful for these cases
JoshSoref: in the case of websockets it might be possible for the websocket api to have a `please send keepalive pings every X units of time`
... And I'm proposing that we change the spec to discourage vendors from implementing it
... including taking up editing the spec to make those changes
... My message outlined an algorithm for addressing the concerns
... implementable in current browsers today without api changes
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0023.html
fjh: ernesto sent a proposal to the list
... dealing with the accept parameter
... he's proposing a favored sequence
<fjh> close ACTION-432
<trackbot> ACTION-432 Make a proposal for ISSUE-116 and ISSUE-117 closed
<fjh> please review your open actions, open actions, http://www.w3.org/2009/dap/track/actions/open
<richt> AOB... fyi, some general background reading on the state of Device APIs from Opera interns: http://publications.lib.chalmers.se/cpl/record/index.xsql?pubid=143816
<richt> might be of interest.
fjh: AnssiK: you're pretty close on battery
... permisions is moving forward
... we need to hash things out on sensors
... the chairs will meet to talk with the WebRTC
... next meeting next week