Device APIs and Policy Working Group Teleconference

<trackbot> Date: 13 July 2011

<fjh> Scribe: Bryan_Sullivan

<fjh> ScribeNick: bryan

<darobin> SungOk_You

Administrative

<fjh> discontinuing UK, FR dial-in zakim numbers

<fjh> http://lists.w3.org/Archives/Member/member-device-apis/2011Jul/0000.html

Media Annotations group is going to last call with Media Annotation Resources and Webapps with WebIDL also

bryan: I will look for internal reviewers on media annotation

<darobin> http://www.w3.org/mid/4E1C8BD6.8020607@w3.org -> MAWG Media Annotation API LC

<darobin> http://www.w3.org/mid/4E1C72C8.9030402@nokia.com -> Web IDL LC

Minutes from July 6 approval

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/att-0062/minutes-2011-07-06.html

<fjh> proposed RESOLUTION: Minutes from 6 July 2011 are approved

RESOLUTION: Minutes from 6 July 2011 are approved

F2F

<fjh> if you plan to use a car please indicate to Cecile

<fjh> http://www.w3.org/2009/dap/wiki/F2F_Agenda_19%2c_20%2c_21_July_2011%2c_Paris

fjh: Any comments or concerns to the agenda?
... Web and TV - plan to introduce by Francois is TBD
... dial-in will be provided
... APIs not progressing will be moved to Day 3

battery

<dom> (we have one open issue ISSUE-112)

<dom> ISSUE-112?

<trackbot> ISSUE-112 -- Do we need to give an estimated time remaining indication with battery events? -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/112

darobin: need to review it before last call

<fjh> diiscovery proposal -> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0073.html

<fjh> event firing issue -> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0070.html

dom: device orientation API that inspired the battery API has a discussion re event firing, the battery API may need to change as a result

darobin: had we removed mention of immediate (firing)

<dom> http://dev.w3.org/2009/dap/system-info/battery-status.html#the-batterystatus---------event

<darobin> "When an event listener is registered with the event type batterystatus, then the user agent must retrieve the relevant information and dispatch a BatteryStatusEvent event asynchronously as defined in [DOM-LEVEL-3-EVENTS]. "

darobin: confirms immediate was removed

<fjh> concern with potential side effects

dom: invoking add event listener should not have side effects

<dom> ISSUE: addEventListener in Battery Status has side effects

<trackbot> Created ISSUE-113 - AddEventListener in Battery Status has side effects ; please complete additional details at http://www.w3.org/2009/dap/track/issues/113/edit .

<dom> ISSUE-113: see http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0070.html

<trackbot> ISSUE-113 AddEventListener in Battery Status has side effects notes added

darobin: to continue discussing at the F2F and make decision on last call then

contacts

fjh: where are we

darobin: at the F2F will review last call comments
... we can go to CR when we have addressed all comments

fjh: should consider vacations

darobin: getting close to end of july with one-week review, effectively Sept before transition

richt: need more implementations and test suites, may need to go back to WD?

fjh: yes, that happens

<dom> [we already have the start of a test suite, fwiw http://w3c-test.org/dap/contacts/tests/ ]

darobin: testing is also planned to discussion at F2F

forpic: other APIs

<dom> (Robin is an editor!)

network information

fjh: can we resolve the ethernet/usb issue

<dom> I think Josh's feedback is close to the feedback we got from Jo, to which our response is still pending (cf ACTION-411)

<dom> ACTION-411?

<trackbot> ACTION-411 -- Robin Berjon to reply to Jo about NetInfo -- due 2011-06-15 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/411

timeless: knowing the wire interface is not useful

dom: we should document the discussion and resolution about the level of information that can be given in the network info API

timeless: agree

richt: have an implementation of the API, for Android browser. changes cost to implementations and need to be factored into the decision

timeless: would be good to know if 4G is ever returned

dom: suggest timeless reach out to google for their input

<richt> as I mentioned last week if we can mark up emails with [contacts] [netinfo] etc then it would be easier for other (busy) people to participate. Parsing all the emails received takes time.

<richt> ...or setup sub-groups.

timeless: will make an effort to reach out

<darobin> [richt: make a proposal to the list]

dom: re proposal to markup subject line on emails, the new charter will enable task forces (with separate mailing lists), and we can also improve email usage in the way suggested - new email lists have a management overhead

bryan: I support use of tags over additional lists

<Zakim> timeless, you wanted to note that having to subscribe to lots of mailing lists or unsubscribe is painful

<richt> '500 emails a day' was conservative. But I was assuming you read them all ;)

timeless: having to subscribe/unsubscribe is painful - tags are better

fjh: tags are probably easier

dom: open to many options but we need people to express themselves

<richt> Should be simple enough to add tags to new email threads. Really helps to focus in on particular subjects at a time.

<richt> It's an informal proposal.

dom: webapps uses tags and also has distinct lists

<dom> let's maybe start with tagging subjects; could the chairs suggest this to the list?

<richt> dom, that's what I mean at [contacts] in the subject line.

darobin: should continue on the list

<richt> It shouldn't need to much discussion. People either do it or we don't.

<wonsuk> +1 for tag, even though it will not be perfect

+1

<Dzung_Tran> +1

someone suggest the tags to use

fjh: AOB?

yes

fjh: no call the week after the F2F