IRC log of dap on 2011-06-29

Timestamps are in UTC.

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