Device APIs and Policy Working Group Teleconference -- 19 May 2010

<trackbot> Created ACTION-173 - Implement privacy changes noted by alissa, see http://lists.w3.org/Archives/Public/public-device-apis/2010May/0072.html [on Max Froumentin - due 2010-05-26].

<fjh> action-173: target is sysinfo

<trackbot> ACTION-173 Implement privacy changes noted by alissa, see http://lists.w3.org/Archives/Public/public-device-apis/2010May/0072.html notes added

<fjh> suresh asks about 4.7, naming

<jmorris> +1 on a complete table

<fjh> suresh talking about table in annex portion of his comments

maxf: will be responding to suresh's concerns one by one on mailing list

rberjon: primary non-editorial concern is the synchronicity of getters
... some sensors might be slow to respond, hence use of async for get

suresh: are we optimizing for corner cases with use of callbacks?
... sysinfo is information you have readily available

<fjh> suresh proposes should use monitor function instead of get in this kind of case

arve: should we really increase API complexity by adding another method for synchronous getters

<fjh> prefer consistency in using async methods, reducing complexity of number of choices

arve: implementors complexity increases by adding synchronous getters

<darobin> [I tend to agree with arve and max, developers are used to using async nowadays]

<maxf> the same argument could be made for Contacts API

<darobin> [privacy and security]

<maxf> Arve: some properties like SSID are static. Privacy sensitive APIs which will ask the user for consent will need asynchronous

<fjh> we agreed on general async approach to avoid blocking, enable privacy consent etc

darobin: will not want to block on modal dialogs

<maxf> webworkers might help, but they wouldn't prevent authors to make blocking dialogs if they wanted.

<fjh> +1 to consistent model, uniformity and enabling flexibility in changing which need consent or dialogs

RESOLUTION: will keep getters asynchronous

<Zakim> fjh, you wanted to ask about minimization, http://lists.w3.org/Archives/Public/public-device-apis/2010May/0076.html

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010May/0076.html

alissa: in terms of the network property

<fjh> network properties minimization

alissa: provide only information about the active connection?

<darobin> [on mobiles, it is common to have 3G and MMS :)]

arve: how common are multiple active connections? e.g. wired and wireless at once etc

<darobin> [in general, I think it makes sense to only expose active connections]

<maxf> it's a reality that devices have more than one connection, but no one seems to know whether it's worth supporting in the API. That's noted in the specification.

alissa: wants to discuss use cases for multiple active connections

<jmorris> also want to know use cases more broadly, for MAC address, SSID, etc.

alissa: do you need to know the sensitive information from particular active or inactive connections

<Zakim> maxf, you wanted to say more

maxf: no proper discussion on the properties in the network interfaces have taken place

<jmorris> +1 on proper discussion

maxf: this would be a good opportunity to initialize this discussion

<fjh> can we use alissa's email as a starting point?

<jmorris> +1 on doing discussion on list

<scribe> ACTION: alissa will provide an initial analysis of properties [recorded in http://www.w3.org/2010/05/19-dap-minutes.html#action02]

<trackbot> Created ACTION-174 - Will provide an initial analysis of properties [on Alissa Cooper - due 2010-05-26].

fjh: do we remove speculation on when we go to CR?
... (on the DAP home page)

Filereader

darobin: discussion about FileReader (by WebApps)
... please provide feedback to that WG, as it is of some importance to this group

<fjh> s/scribenick arve//

Device APIs and Policy Working Group Teleconference

19 May 2010

Attendees

Contents

Administrative

Minutes approval

Policy requirements

APIs

Filereader

Summary of Action Items