See also: IRC log
<trackbot> Date: 14 November 2012
<scribe> ScribeNick: fjh
fjh: No call next week, next call on 28 November.
... no other announcements, apart from welcome to new participants http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0026.html
fjh: F2F minutes to be published, anticipate will approve on 28 November.
... I sent Informal chair notes on F2F: http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0020.html
Web Based Signage slides from F2F: http://www.w3.org/community/websignage/wiki/images/3/30/Tpac2012_signage_bg_discovered_by_personal_devices.pdf
fjh: Mounir updated the editors draft, http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html
ACTION-590?
<trackbot> ACTION-590 -- Mounir Lamouri to prepare updated WD of network information with updated status, including addition of use cases -- due 2012-11-08 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/590
close ACTION-590
<trackbot> ACTION-590 Prepare updated WD of network information with updated status, including addition of use cases closed
fjh: I sent some comments to the list
... I think the test in example 3 may require a "not", http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0030.html
<AnssiK> +1 to publish an updated WD
fjh: I suggest we get this published as an updated WD, with the changes I proposed (assuming Mounir agrees). An improvement over what is in TR
... any objection to publishing updated WD?
RESOLUTION: publish updated WD of Network Information API using updated editors draft with changes proposed by Frederick, as agreed by Mounir
<scribe> ACTION: fjh to arrange publication of updated WD of Network Information API [recorded in http://www.w3.org/2012/11/14-dap-minutes.html#action01]
<trackbot> Created ACTION-594 - Arrange publication of updated WD of Network Information API [on Frederick Hirsch - due 2012-11-21].
fjh: no need for CfC for this, as we agreed at F2F this is necessary and it is an update of a WD
CfC to publish Last Call, http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0002.html
fjh: agreement on the list add a text field for which sensor
http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0029.html
fjh: concerns with this, seems to be agreement on list
anssik: note that CfC was for ambient light
fjh: my mistake in reading the draft minutes, we already agreed
... will publish in conjunction with ambient light
... concerns with adding field?
anssik: we should have some implementation experience, concern about arbitrary text field
fjh: anssi can you please comment on the list with the concern?
anssik: yes, will do. we should give this a bit of time
fjh: defer decision to publish until this is resolved, I note that CfC for publishing ambient light has completed (as of yesterday) with no objection
... so we can publish both once ready, i.e. when we have resolved this field discussion
... it would be good to get Last Call published before we hit the holiday period, perhaps we can resolve by 28 November.
anssik: are you proposing we publish both together?
fjh: yes, it is less work for team, less confusing for Last Call timing, etc
anssik: suggest we might not want to add the field, not to hold up
fjh: this is a generic problem - which sensor, which camera etc
anssik: problem in touch as well, which touch point
... might not be as simple as adding a string
fjh: not sure, this seems to warrant list discussion
... let's try to resolve this on the list so we can arrange publication of Last Call week of 28 Nov
fjh: I sent proposed changes: http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0024.html
anssik: looks good, will wait a few days for feedback then incorporate
fjh: would prefer to have changes in place to share with Doug
... and others
anssik: ok, will make the changes now so we can share updated editors draft showing changes in place
fjh: Thanks - will need to work through remaining comments, but I'd like to do this first as it may resolve others as well
fjh: much discussion on list, not sure where it leaves us
anssik: david bryant would like us to expose maximum duration of vibration time through API
fjh: debate of whether that is meaningful
anssik: correct, may wish to keep API simpler, avoid misuse
... golden rule of api design, minimize surface, not convinced that this is an issue with any implementations
fjh: how to bring this to closure?
anssik: asked David to experiment with implementations, to see if concerns are valid. He wrote code instead, showing how you can determine maximum length seeing when exception is thrown
... no high value use case for adding field
fjh: we will need explicit WG decision
anssik: yes, also need implementers view
... user configurable in firefox
... web developer should not know this information, typical in web, web developer does not have much detail on user agent
... limits may be UA dependent
... similar to requiring certain screen resolutions when browsing the web, a bad idea
... do not want web developers to design app with this in mind
fjh: sounds like two different use cases - one where it just vibrates, another with a time of vibration
anssik: should not put in API unless we really need it
... mozilla did not include, proving the point
fjh: suggest you send email to list suggesting we not add this, noting reasons discussed here.
anssik: will do this
none today
ACTION-593?
<trackbot> ACTION-593 -- Dominique Hazaël-Massieux to build a survey for finding a week for DAP meeting March/April -- due 2012-11-09 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/593
ACTION-587?
<trackbot> ACTION-587 -- Anssi Kostiainen to prepare Proximity LC draft and run through pubrules -- due 2012-11-08 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/587
anssik: I should have this for the next call
fjh: please review the list at http://www.w3.org/2009/dap/track/actions/open
none
reminder, No call next week, next call on 28 November.