13:46:40 RRSAgent has joined #dap 13:46:40 logging to http://www.w3.org/2011/06/29-dap-irc 13:46:42 RRSAgent, make logs world 13:46:42 Zakim has joined #dap 13:46:44 Zakim, this will be DAP 13:46:44 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 14 minutes 13:46:45 Meeting: Device APIs and Policy Working Group Teleconference 13:46:45 Date: 29 June 2011 13:47:55 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0091.html 13:50:28 Kihong_Kwon has joined #dap 13:51:10 Present+ Kihong_Kwon 13:51:41 Regrets+ Suresh_Chitturi, Wonsuk_Lee, Rich_Tibbett 13:51:58 Chair: Robin_Berjon, Frederick_Hirsch 13:52:10 Present+ Robin_Berjon, Frederick_Hirsch 13:53:00 Present+ Josh_Soref 13:53:37 fjh_ has joined #dap 13:55:14 Regrets+ Ernesto_Jimenez, Dzung_Tran 13:55:40 fjh__ has joined #dap 13:56:25 UW_DAP()10:00AM has now started 13:56:32 +SHayman 13:57:07 +??P20 13:57:08 Zakim, SHayman is really jsoref 13:57:08 +jsoref; got it 13:57:12 Zakim, ??P20 is me 13:57:12 +darobin; got it 13:57:39 +??P6 13:57:41 zakim, ?? is me 13:57:41 +fjh; got it 13:57:47 zakim, who is here? 13:57:47 On the phone I see jsoref, darobin, fjh 13:57:48 On IRC I see fjhother, Kihong_Kwon, Zakim, RRSAgent, fjh, darobin, ingmar, ilkka, jsoref, lgombos, wmaslowski, dom, trackbot 13:58:13 +??P29 13:58:20 Zakim, ??P29 is me 13:58:20 +dom; got it 13:58:32 Present+ Dominique_Hazael-Massieux 13:59:08 -fjh 13:59:35 ScribeNick: jsoref 13:59:58 +??P6 14:00:00 Scribe: Josh_Soref 14:00:03 zakim, ?? is me 14:00:03 +fjhother; got it 14:00:30 Zakim, who's on the call? 14:00:30 On the phone I see jsoref, darobin, dom, fjhother 14:00:34 ScribeNick: jsoref 14:00:43 + +1.781.534.aaaa 14:01:02 Zakim: Present+ Laszlo_Gombos 14:01:26 AnssiK has joined #dap 14:01:34 Present+ Laszlo_Gombos 14:01:39 zakim, who is here? 14:01:41 On the phone I see jsoref, darobin, dom, fjhother, +1.781.534.aaaa 14:01:49 On IRC I see AnssiK, fjhother, Kihong_Kwon, Zakim, RRSAgent, fjh, darobin, ingmar, ilkka, jsoref, lgombos, wmaslowski, dom, trackbot 14:01:58 zakim, aaaa is lgombos 14:01:58 +??P32 14:02:02 +lgombos; got it 14:02:03 zakim, ??P32 is me 14:02:08 +AnssiK; got it 14:02:16 Present+ Anssi_Kostiainen 14:02:33 Zakim, who's on the call? 14:02:33 zakim, who is here? 14:02:40 On the phone I see jsoref, darobin, dom, fjhother, lgombos, AnssiK 14:02:48 On the phone I see jsoref, darobin, dom, fjhother, lgombos, AnssiK 14:02:54 On IRC I see AnssiK, fjhother, Kihong_Kwon, Zakim, RRSAgent, fjh, darobin, ingmar, ilkka, jsoref, lgombos, wmaslowski, dom, trackbot 14:03:52 fjh: First topic is administrative 14:03:55 19-21 July F2F logistics, http://lists.w3.org/Archives/Member/member-device-apis/2011Apr/0000.html 14:03:55 Please register - http://www.w3.org/2002/09/wbs/43696/paris-2011/ 14:03:57 Topic: Administrative 14:04:08 Publishing moratorium 24-29 July 14:04:08 http://lists.w3.org/Archives/Member/member-device-apis/2011Jun/0011.html 14:04:10 [registration expires on the 12th] 14:04:11 Cathy has joined #dap 14:04:13 cmarc has joined #dap 14:04:13 -AnssiK 14:04:31 Hi, I'm Josh Soref, I recently joined Research In Motion, to officially work on Web Standards. 14:04:36 And I'm glad to be here 14:04:43 Present+ Cathy_Chan 14:04:47 +??P32 14:04:54 zakim, ??P32 is me 14:04:54 +AnssiK; got it 14:05:02 +Cecile_Marc 14:05:03 Present+ Cecile_Marc 14:05:49 dom: I wasn't on last week's call because I welcomed my second son. He's also why I won't be at the f2f 14:05:58 congratulations 14:05:59 François Daoust 14:06:03 +Cathy 14:06:05 a.k.a tidoust 14:06:14 ... François Daoust will be at the f2f in my stead 14:06:35 Topic: Minutes approval 14:06:38 http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/att-0055/minutes-2011-06-15.html 14:06:39 fjh: any concerns? 14:06:50 Proposed Resolution: accept minutes 14:07:16 s/accept minutes/15 june 2011 are approved/ 14:07:39 nwidell has joined #dap 14:07:50 Resolution: 15 june 2011 minutes are approved 14:07:50 -Cathy 14:07:52 s/Resolution/RESOLUTION 14:08:06 + +46.1.07.15.aabb 14:08:22 Topic: Charter 14:08:28 Present+ Niklas_Widell 14:08:31 fjh: Discovery... 14:08:34 Review completed, see http://www.w3.org/2002/09/wbs/33280/dap-2/results 14:08:34 Possible clarification needed on scope of discovery 14:08:38 ... whether it should be in the charter or not 14:08:42 zakim, aabb is nwidell 14:08:42 +nwidell; got it 14:08:56 ,,, i don't know what to do, dom, it seems like we need a couple of sentences 14:09:03 s/,,,/.../ 14:09:22 dom: roughly speaking, i will be working with the team on trying to find a position that is agreeable to all 14:09:27 team will be working on updates to charter from this point 14:09:41 ... this would affect whether it's present in the charter or not 14:09:41 + +1.781.312.aacc 14:09:49 zakim, aacc is me 14:09:49 +Cathy; got it 14:09:50 ... the current charter runs through July 2 14:09:58 ... so we have a little leeway 14:10:01 s/July 2/July 31/ 14:10:06 Topic: Battery Specification 14:10:24 AnssiK: I received some feedback from the Web Performance WG 14:10:27 ... they liked it 14:10:32 ... they liked the simplicity of it 14:10:44 ... I also received editorial feedback from josh 14:10:54 ... that's reflected in the ED 14:11:06 ... the webkit team has a draft implementation of the ED 14:11:15 ... I'd like to summarize the status.... 14:11:20 ... the spec is terribly simple 14:11:26 ... i'd like to go to LC 14:11:27 Wonsuk has joined #dap 14:11:52 ... I'd rather address josh's other feedback in a later spec 14:12:03 ... We also received feedback from Doug Turner of Mozilla 14:12:10 Present+ Wonsuk_Lee 14:12:12 ... Josh's feedback is good, but... 14:12:14 +1 on more than level-based events 14:12:26 +1 as well 14:12:28 fjk: it seems to me that some of josh's comments should be dealt with later 14:12:44 AnssiK: i'd like to put them in a bucket that can be in Version 2 of the specification 14:12:49 s/fjk/fjh 14:12:50 ... a question to Josh: 14:12:54 I would put Critical/Low events in v1 rather than v2 14:13:03 ... do you think that the ideas that you have could be built on top of the current version? 14:13:08 I would, too 14:13:11 ... if that's the case, then i'd rather go out with what we have now 14:13:19 ... and then when we have more implementation experience 14:13:27 ... we could got out with the current spec 14:13:32 ... and then extend it later 14:13:41 [ scribe pauses to compose thoughts ] 14:14:21 q+ to clarify that there's no rush to LC — we have good feedback, what's more from implementers, I think we should take it for v1 14:14:26 josh notes concern of having to replicate implementation of higher level functions if not provided as part of the api 14:15:27 josh notes concern about having to have continuously running app to learn about device battery use, self-defeating to use up battery 14:16:19 [I'm not sure OS can report useful data about battery time left in the first place 14:16:22 josh notes that knowing that battery is low or critically low is not useful, since app cannot interpret this in terms of time left etc 14:16:35 [no, but it's the most accurate you'll ever get] 14:17:07 q+ 14:17:13 josh notes some laptops are able to handle this time left function 14:17:15 [we could add an "estimatedTimeLeft" attribute added to the event?] 14:17:24 q? 14:17:41 ack me 14:17:41 darobin, you wanted to clarify that there's no rush to LC — we have good feedback, what's more from implementers, I think we should take it for v1 14:17:43 josh suggests no rush to go to last call 14:17:58 darobin: I just wanted to point out that irrespective of technical arguments 14:18:01 ... there's no rush to LC 14:18:13 ... there's no rush to have a short spec and go to rec immediately 14:18:18 ... i think we have good feedback 14:18:26 ... from implementers 14:18:33 ... i think that this spec should be so simple 14:18:38 +1 to robin 14:18:44 ... that there perhaps should never be a need for a v2 14:18:46 q+ to ask if the spec is layered 14:18:55 ack anssiK 14:18:55 ack AnssiK 14:19:04 AnssiK: my question that was not answered 14:19:12 ... can we layer this functionality on the existing api? 14:19:19 ... josh's proposal 14:19:25 ... or doug's proposal 14:19:43 darobin: for the semantic events 14:19:49 ... the problem is that the only thing that javascript can do 14:19:55 ... is have some very rough heuristics 14:20:04 ... on some devices, 10% is extremely low 14:20:17 ... on other devices you still have 1 1/2 hrs of battery 14:20:22 ... the system has this information 14:20:29 ... if that information is available, then we should use those 14:20:44 Zakim, mute jsoref 14:20:44 jsoref should now be muted 14:20:46 ... it certainly doesn't make sense for a script to start saving battery if you have 2 hours left 14:20:54 AnssiK: by layering on top 14:21:08 +1 to robin and josh that having time left is very useful if possible 14:21:09 ... i mean can we just add another api past it 14:21:31 darobin: so battery events level 2 that is other stuff past level one 14:21:38 AnssiK: if someone implements the current draft 14:21:46 ... does it do something useful toward level 2 14:21:58 q+ 14:21:58 darobin: i'm a bit concerned that for something as simple as a battery specification 14:22:04 ... that we might be producing multiple specs 14:22:07 q+ 14:22:13 ... layering is very nice 14:22:16 ack fjh 14:22:16 fjh, you wanted to ask if the spec is layered 14:22:20 ... but i'm concerned that we may be doing too much of it 14:22:26 fjh: i have another question 14:22:32 ... josh asked about continuously polling 14:22:38 ... i think we would want to avoid that 14:22:44 ... do we think it would be 3 months? 14:22:53 darobin: i said 3 months because it was the first figure that came 14:23:04 ... i don't think that it would take that long to integrate the current feedback 14:23:15 fjh: i think the webkit feedback asked about use cases 14:23:24 ... i think that josh is expanding the use cases 14:23:30 ... i don't think that we thought about those use cases 14:23:50 lgombos: there was some feedback from the webkit community about use cases 14:24:02 ... i think we answered them 14:24:26 ... that it was just for telling the web page that it needs to save its state because it's running low 14:24:39 ... initially the use case is just very basic power management for the web page 14:24:46 [ the use case request on the webkit-dev was about the Contacts API ] 14:24:48 q? 14:24:53 fjh: thanks, i think you're saying we don't need to expand the use cases much 14:24:54 ack dom 14:25:05 dom: i think it's actually useful to document the use cases we think we are solving 14:25:06 +1 to documenting use cases 14:25:13 ... the reason i think we should include critical and low events 14:25:20 ... and also remaining time 14:25:25 q+ 14:25:29 ... i think that the changes needed are fairly low 14:25:30 documenting use case should help set appropriate expectations 14:25:36 +10 to someone taking an action item to document use cases :) 14:25:39 ... i think there's much more value in integrating them now 14:25:48 ack jsoref 14:25:49 q? 14:25:52 ... because they will actually match the use cases people will need 14:26:24 q? 14:26:25 ack anssiK 14:26:27 q+ to note that timeRemaining was in but was dropped due to implementer's feedback 14:26:29 ack me 14:26:29 AnssiK, you wanted to note that timeRemaining was in but was dropped due to implementer's feedback 14:26:33 ack fjh 14:26:33 fjh, you wanted to subject 14:26:46 AnssiK: timeRemaining was in, but was dropped due to implementer's feedback 14:26:51 ... it's easy to put that part back in 14:26:56 ... if we wish to do that 14:26:58 q+ 14:27:01 [actually I think it was my feedback that dropped it] 14:27:07 Zakim: mute me 14:27:19 Zakim, must jsoref 14:27:19 I don't understand 'must jsoref', darobin 14:27:20 AnssiK: Opera is running across multiple platforms 14:27:30 Zakim, mute jsoref 14:27:30 jsoref should now be muted 14:27:48 ... and they indicated that they had trouble implementing it across platforms 14:27:48 [I think .timeRemaining would be set to null if it can't be detected] 14:28:08 darobin: if i recall correctly, it was removed 14:28:17 ... because i looked and saw it wasn't available in low level apis 14:28:23 AnssiK: i think rich also raised some concerns 14:28:35 ... so it was your [ darobin ] feedback and his 14:28:52 darobin: i think we could do it as dom suggested, using null otherwise 14:29:01 ... i think all the desktop low level apis provide it 14:29:09 ... and it's quite possible that iOS 5 may have it 14:29:13 ... and Android has it 14:29:25 ... if it's something that people want and there are use cases 14:29:35 ... i'm less convinced that it's more useful than semantic 14:29:42 q+ to talk about update notifications 14:29:45 q? 14:29:52 ack lgombos 14:29:52 -> http://lists.w3.org/Archives/Public/public-device-apis/2011May/0043.html Robin's review of other platform battery APIs 14:29:53 ack lgombos 14:29:53 fjh: so where does that leave us? i thought we were going to LC 14:30:07 lgombos: I'm also questioning time remaining as a feature, both from use cases 14:30:12 ... and also from feasibility 14:30:12 "So the first conclusion I have is that we can kill timeRemaining. It doesn't seem to be available outside of desktop APIs (which are far more complete, including UPS support and all that)." -- Robin in that message 14:30:22 ... i think time remaining is predicting the future 14:30:32 ... people can claim to be good at it 14:30:38 ... but it can change drastically 14:30:53 ... i think signalling you have 5 minutes left to the web page can be confusing 14:30:55 (well, the spec could make it clear this is an estimation; it could even be called estimatedTimeRemaining if we prefer clarity to concision] 14:31:00 ... if it turns out to be wrong 14:31:11 ... i'm not sure what the web page can do with 5 mintues left v. 10 minutes left 14:31:18 (but I agree that the needs for timeRemaining is less than the need for semantic events) 14:31:18 ack jsoref 14:31:20 jsoref, you wanted to talk about update notifications 14:31:23 ... i kind of understand how semantic events could be useful 14:31:31 s/is less/are less clear/ 14:31:34 [I tend to agree that the use cases for semantic events are strong, for timeRemaining I'm not yet convinced (but will go with the group's consensus)] 14:32:59 (I think the Critical event would address that use case) 14:33:51 josh notes use case where writing to disk or network is expensive and that app could defer writes if knows there is enough battery to wait 14:34:11 s/expensive/expensive (both power and timewise)/ 14:34:12 josh notes that app could learn from system if time estimate needs adjustment 14:34:31 [I agree with dom] 14:34:52 josh asks "what does critical mean to app" 14:35:35 seems to me we have a fundamental disconnect here between higher level functionality and knowing what it means in terms of battery, not so deterministic 14:36:32 darobin: josh, i think your cases are somewhat contrived 14:36:40 q? 14:36:41 ... when i got a low message, i'd start saving everything 14:36:47 ... and when i get critical, i'd give up 14:36:50 Zakim, mute jsoref 14:36:50 jsoref should now be muted 14:37:08 ... you generally need to save regularly anyway 14:37:10 q? 14:37:13 ... since you can't be sure you won't crash 14:38:06 PROPOSED RESOLUTION: we should wait a bit before we go further. And that we want to accept some of the feedback. Most people agree that semantic events are useful. 14:38:22 fjh: Some people wonder if they're practical 14:38:37 darobin: the difference is, if we don't agree that we might want them, then we do no work at all 14:38:48 ... if we do agree that they're useful, then we look into the practicality of implementing them 14:38:54 ... as for time remaining, it's less clear 14:39:00 q+ 14:39:05 ... i'm not sure we have consensus to remove it 14:39:09 ack AnssiK 14:39:10 ack AnssiK 14:39:10 ack AnssiK 14:39:28 ISSUE: do we need to give an estimated time remaining indication with battery events? 14:39:28 Created ISSUE-112 - Do we need to give an estimated time remaining indication with battery events? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/112/edit . 14:39:38 AnssiK: for Semantic events, is it just a matter of dispatching an event with the same information, but a different name? 14:39:45 ... possibly with timeRemaining 14:39:51 ... that's easy for spec writing 14:40:03 ... the harder part is coming up with the prose 14:40:19 darobin: i'm not sure that we need to provide much prose 14:40:24 Kangchan has joined #dap 14:40:30 ... we can leave it to the implementation 14:40:41 ... they can use whatever the system gives to them 14:40:50 Wonsuk has left #dap 14:40:56 ... two different UAs on the same device should give roughly the same event at the same time 14:41:09 AnssiK: that's so simple that i could do it right away 14:41:17 ... we could bike shed the event names :) ... 14:41:23 Wonsuk has joined #dap 14:41:25 ... that's the longest part of the work 14:41:29 Present+ Kangchan_Lee 14:41:36 ... after that, we'd like to get implementer feedback 14:41:45 ... but then again, they might not be looking at the spec with those glasses on 14:41:54 ... - what developers need - 14:42:02 ... just from an implementer's point of view 14:42:11 darobin: for bike shedding, i'm open to the editor 14:42:15 BatteryLow, BatteryCritical :) 14:42:17 AnssiK: editor is open to suggestions (by irc) 14:42:33 all lowercase indeed 14:42:34 ... are there best practices ... all lower case? camel case? 14:42:41 -fjhother 14:42:50 batterylow, batterycritical 14:42:56 AnssiK: doug raised an important point 14:43:02 +??P4 14:43:06 ... should we expose this to the global namespace or not? 14:43:06 zakim, ?? is me 14:43:06 +fjh; got it 14:43:19 ... doug was thinking we should only expose it via AddEventListener 14:43:24 ... and not window. 14:43:30 darobin: I don't see the use case for having it on window 14:43:35 +1 14:43:46 AnssiK: it's currently on window, but we could just get rid of it 14:43:54 ... there are lots of legacy items on window 14:43:55 +1 on not having it on onwindow 14:44:02 s/onwindow/on window/ 14:44:12 s/on on window/on window/ 14:44:22 AnssiK: it seems to me that there's no established best practice 14:44:31 I think DeviceOrientaiton is considering removing it, have asked Hixie for feedback 14:44:51 darobin: i wouldn't take inspiration from DeviceOrientation 14:44:55 ... because it isn't finalized 14:45:05 darobin: the only thing is detection 14:45:17 AnssiK: i looked at the modernizer component 14:45:27 ... and it does detection based on interface existance 14:46:06 darobin: the other thing you can do is detect if asking for the event results in an event immediately 14:46:31 AnssiK: points... whether we drop the window. 14:46:38 ... and also the body. 14:46:43 ... whether we should drop both 14:46:49 ... and do what doug suggested 14:47:05 ... i looked at bugzilla.mozilla.org and saw that ... i think offline/online events 14:47:15 PROPOSED RESOLUTION: we should wait a bit before we go further. And that we want to accept some of the feedback. Most people agree that semantic events are useful. Time remaining has ISSUE-112. Remove onfoo on window and body 14:47:16 ... and it seems initially it was exposed on window, and then later removed 14:47:21 ... i think josh remembers it 14:47:27 yes, I remember it being removed 14:47:48 AnssiK: josh: do you remember the infrastructure behind events 14:48:11 RESOLUTION: we should wait a bit before we go further. And that we want to accept some of the feedback. Most people agree that semantic events are useful. Time remaining has ISSUE-112. Remove onfoo on window and body 14:48:16 q+ 14:48:24 ACTION AnssiK to remove window/body.onfoo 14:48:24 Sorry, couldn't find user - AnssiK 14:48:30 ACTION: Anssi to implement changes to battery event based on feedback, and RESOLUTION from 20110629 14:48:31 Created ACTION-417 - Implement changes to battery event based on feedback, and RESOLUTION from 20110629 [on Anssi Kostiainen - due 2011-07-06]. 14:48:50 dom: how do we make progress on time remaining 14:48:57 darobin: i don't know... 14:49:02 ... do we look at use cases? 14:49:07 ... and decide if they're necessary? 14:49:14 ... or are we more concerned about implementability 14:49:17 dom: i think it's both 14:49:34 ... maybe we can give an action item to josh 14:49:43 zakim, who is here? 14:49:43 On the phone I see jsoref (muted), darobin, dom, lgombos, AnssiK, Cecile_Marc, nwidell, Cathy, fjh 14:49:44 ... to identify use cases that require time remaining 14:49:46 On IRC I see Wonsuk, Kangchan, nwidell, cmarc, Cathy, AnssiK, fjhother, Kihong_Kwon, Zakim, RRSAgent, fjh, darobin, ingmar, ilkka, jsoref, lgombos, wmaslowski, dom, trackbot 14:49:47 unmute jsoref 14:49:57 ack jsoref 14:50:33 ACTION: Josh to formulate the use cases he sees for timeRemaining, and if possible an implementation strategy for when that information isn't provided by the OS 14:50:33 Created ACTION-418 - Formulate the use cases he sees for timeRemaining, and if possible an implementation strategy for when that information isn't provided by the OS [on Josh Soref - due 2011-07-06]. 14:50:36 -nwidell 14:51:17 AnssiK: should i formulate something for semantic events in the ED now 14:51:19 ... or ask the list 14:51:27 darobin: I think you should just change the ED and notify the list 14:51:37 Zakim, mute me 14:51:37 jsoref should now be muted 14:51:48 darobin: the list needs to be notified at some point 14:51:59 ... to inform people that the changes have been taken into account 14:52:05 (I think fixing the draft first makes it clearer) 14:52:07 AnssiK: so there's no preference in the group 14:52:32 darobin: i have a preference for not having a discussion about commit-then-review or review-then-commit 14:52:40 ... because i have had that discussion too many times recently 14:52:42 +1 14:52:46