Device APIs and Policy Working Group Teleconference

<trackbot> Date: 29 June 2011

<scribe> ScribeNick: jsoref

<scribe> Scribe: Josh_Soref

<fjhother> ScribeNick: jsoref

<lgombos> Zakim: Present+ Laszlo_Gombos

fjh: First topic is administrative

<fjh> 19-21 July F2F logistics, http://lists.w3.org/Archives/Member/member-device-apis/2011Apr/0000.html

<fjh> Please register - http://www.w3.org/2002/09/wbs/43696/paris-2011/

Administrative

<fjh> Publishing moratorium 24-29 July

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

<darobin> [registration expires on the 12th]

Hi, I'm Josh Soref, I recently joined Research In Motion, to officially work on Web Standards.

And I'm glad to be here

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

<cmarc> congratulations

<darobin> François Daoust

<darobin> a.k.a tidoust

dom: François Daoust will be at the f2f in my stead

Minutes approval

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/att-0055/minutes-2011-06-15.html

fjh: any concerns?

Proposed Resolution: 15 june 2011 are approved

RESOLUTION: 15 june 2011 minutes are approved

Charter

fjh: Discovery...

<fjh> Review completed, see http://www.w3.org/2002/09/wbs/33280/dap-2/results

<fjh> Possible clarification needed on scope of discovery

fjh: whether it should be in the charter or not
... i don't know what WG can do at this point, Dom, it seems like we need a couple of sentences

dom: roughly speaking, i will be working with the team on trying to find a position that is agreeable to all

<fjh> team will be working on updates to charter from this point

dom: this would affect whether it's present in the charter or not
... the current charter runs through July 31
... so we have a little leeway

Battery Specification

AnssiK: I received some feedback from the Web Performance WG
... they liked it
... they liked the simplicity of it
... I also received editorial feedback from josh
... that's reflected in the ED
... the webkit team has a draft implementation of the ED
... I'd like to summarize the status....
... the spec is terribly simple
... i'd like to go to LC
... I'd rather address josh's other feedback in a later spec
... We also received feedback from Doug Turner of Mozilla
... Josh's feedback is good, but...

<dom> +1 on more than level-based events

<darobin> +1 as well

fjh: it seems to me that some of josh's comments should be dealt with later

AnssiK: i'd like to put them in a bucket that can be in Version 2 of the specification
... a question to Josh:

<dom> I would put Critical/Low events in v1 rather than v2

AnssiK: do you think that the ideas that you have could be built on top of the current version?

<darobin> I would, too

AnssiK: if that's the case, then i'd rather go out with what we have now
... and then when we have more implementation experience
... we could got out with the current spec
... and then extend it later

[ scribe pauses to compose thoughts ]

<fjh> josh notes concern of having to replicate implementation of higher level functions if not provided as part of the api

<fjh> josh notes concern about having to have continuously running app to learn about device battery use, self-defeating to use up battery

<dom> [I'm not sure OS can report useful data about battery time left in the first place

<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

<darobin> [no, but it's the most accurate you'll ever get]

<fjh> josh notes some laptops are able to handle this time left function

<dom> [we could add an "estimatedTimeLeft" attribute added to the event?]

<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

<fjh> josh suggests no rush to go to last call

darobin: I just wanted to point out that irrespective of technical arguments
... there's no rush to LC
... there's no rush to have a short spec and go to rec immediately
... i think we have good feedback
... from implementers
... i think that this spec should be so simple

<dom> +1 to robin

darobin: that there perhaps should never be a need for a v2

AnssiK: my question that was not answered
... can we layer this functionality on the existing api?
... josh's proposal
... or doug's proposal

darobin: for the semantic events
... the problem is that the only thing that javascript can do
... is have some very rough heuristics
... on some devices, 10% is extremely low
... on other devices you still have 1 1/2 hrs of battery
... the system has this information
... if that information is available, then we should use those
... it certainly doesn't make sense for a script to start saving battery if you have 2 hours left

AnssiK: by layering on top

<fjh> +1 to robin and josh that having time left is very useful if possible

AnssiK: i mean can we just add another api past it

darobin: so battery events level 2 that is other stuff past level one

AnssiK: if someone implements the current draft
... does it do something useful toward level 2

darobin: i'm a bit concerned that for something as simple as a battery specification
... that we might be producing multiple specs
... layering is very nice

<Zakim> fjh, you wanted to ask if the spec is layered

darobin: but i'm concerned that we may be doing too much of it

fjh: i have another question
... josh asked about continuously polling
... i think we would want to avoid that
... do we think it would be 3 months?

darobin: i said 3 months because it was the first figure that came
... i don't think that it would take that long to integrate the current feedback

fjh: i think the webkit feedback asked about use cases
... i think that josh is expanding the use cases
... i don't think that we thought about those use cases

lgombos: there was some feedback from the webkit community about use cases
... i think we answered them
... that it was just for telling the web page that it needs to save its state because it's running low
... initially the use case is just very basic power management for the web page

<AnssiK> [ the use case request on the webkit-dev was about the Contacts API ]

fjh: thanks, i think you're saying we don't need to expand the use cases much

dom: i think it's actually useful to document the use cases we think we are solving

<darobin> +1 to documenting use cases

dom: the reason i think we should include critical and low events
... and also remaining time
... i think that the changes needed are fairly low

<fjh> documenting use case should help set appropriate expectations

<darobin> +10 to someone taking an action item to document use cases :)

dom: i think there's much more value in integrating them now
... because they will actually match the use cases people will need

<Zakim> AnssiK, you wanted to note that timeRemaining was in but was dropped due to implementer's feedback

<Zakim> fjh, you wanted to subject

AnssiK: timeRemaining was in, but was dropped due to implementer's feedback
... it's easy to put that part back in
... if we wish to do that

<darobin> [actually I think it was my feedback that dropped it]

AnssiK: Opera is running across multiple platforms
... and they indicated that they had trouble implementing it across platforms

<dom> [I think .timeRemaining would be set to null if it can't be detected]

darobin: if i recall correctly, it was removed
... because i looked and saw it wasn't available in low level apis

AnssiK: i think rich also raised some concerns
... so it was your [ darobin ] feedback and his

darobin: i think we could do it as dom suggested, using null otherwise
... i think all the desktop low level apis provide it
... and it's quite possible that iOS 5 may have it
... and Android has it
... if it's something that people want and there are use cases
... i'm less convinced that it's more useful than semantic

<dom> Robin's review of other platform battery APIs

fjh: so where does that leave us? i thought we were going to LC

lgombos: I'm also questioning time remaining as a feature, both from use cases
... and also from feasibility

<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

lgombos: i think time remaining is predicting the future
... people can claim to be good at it
... but it can change drastically
... i think signalling you have 5 minutes left to the web page can be confusing

<dom> (well, the spec could make it clear this is an estimation; it could even be called estimatedTimeRemaining if we prefer clarity to concision]

lgombos: if it turns out to be wrong
... i'm not sure what the web page can do with 5 mintues left v. 10 minutes left

<dom> (but I agree that the needs for timeRemaining are less clear than the need for semantic events)

<Zakim> jsoref, you wanted to talk about update notifications

lgombos: i kind of understand how semantic events could be useful

<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)]

<dom> (I think the Critical event would address that use case)

<fjh> josh notes use case where writing to disk or network is expensive (both power and timewise) and that app could defer writes if knows there is enough battery to wait

<fjh> josh notes that app could learn from system if time estimate needs adjustment

<darobin> [I agree with dom]

<fjh> josh asks "what does critical mean to app"

<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

darobin: josh, i think your cases are somewhat contrived
... when i got a low message, i'd start saving everything
... and when i get critical, i'd give up
... you generally need to save regularly anyway
... since you can't be sure you won't crash

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.

fjh: Some people wonder if they're practical

darobin: the difference is, if we don't agree that we might want them, then we do no work at all
... if we do agree that they're useful, then we look into the practicality of implementing them
... as for time remaining, it's less clear
... i'm not sure we have consensus to remove it

<dom> ISSUE: do we need to give an estimated time remaining indication with battery events?

<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 .

AnssiK: for Semantic events, is it just a matter of dispatching an event with the same information, but a different name?
... possibly with timeRemaining
... that's easy for spec writing
... the harder part is coming up with the prose

darobin: i'm not sure that we need to provide much prose
... we can leave it to the implementation
... they can use whatever the system gives to them
... two different UAs on the same device should give roughly the same event at the same time

AnssiK: that's so simple that i could do it right away
... we could bike shed the event names :) ...
... that's the longest part of the work
... after that, we'd like to get implementer feedback
... but then again, they might not be looking at the spec with those glasses on
... - what developers need -
... just from an implementer's point of view

darobin: for bike shedding, i'm open to the editor

<darobin> BatteryLow, BatteryCritical :)

AnssiK: editor is open to suggestions (by irc)

<dom> all lowercase indeed

AnssiK: are there best practices ... all lower case? camel case?

<darobin> batterylow, batterycritical

AnssiK: doug raised an important point
... should we expose this to the global namespace or not?
... doug was thinking we should only expose it via AddEventListener
... and not window.<foo>

darobin: I don't see the use case for having it on window

+1

AnssiK: it's currently on window, but we could just get rid of it
... there are lots of legacy items on window

<dom> +1 on not having it on window

AnssiK: it seems to me that there's no established best practice

<dom> I think DeviceOrientaiton is considering removing it, have asked Hixie for feedback

darobin: i wouldn't take inspiration from DeviceOrientation
... because it isn't finalized
... the only thing is detection

AnssiK: i looked at the modernizer component
... and it does detection based on interface existance

darobin: the other thing you can do is detect if asking for the event results in an event immediately

AnssiK: points... whether we drop the window.<onstuff>
... and also the body.<onstuff>
... whether we should drop both
... and do what doug suggested
... i looked at bugzilla.mozilla.org and saw that ... i think offline/online events

<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

AnssiK: and it seems initially it was exposed on window, and then later removed
... i think josh remembers it

yes, I remember it being removed

AnssiK: josh: do you remember the infrastructure behind events

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

ACTION AnssiK to remove window/body.onfoo

<darobin> ACTION: Anssi to implement changes to battery event based on feedback, and RESOLUTION from 20110629 [recorded in http://www.w3.org/2011/06/29-dap-minutes.html#action01]

<trackbot> Created ACTION-417 - Implement changes to battery event based on feedback, and RESOLUTION from 20110629 [on Anssi Kostiainen - due 2011-07-06].

dom: how do we make progress on time remaining

darobin: i don't know...
... do we look at use cases?
... and decide if they're necessary?
... or are we more concerned about implementability

dom: i think it's both
... maybe we can give an action item to josh
... to identify use cases that require time remaining

<fjh> unmute jsoref

<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 [recorded in http://www.w3.org/2011/06/29-dap-minutes.html#action02]

<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].

AnssiK: should i formulate something for semantic events in the ED now
... or ask the list

darobin: I think you should just change the ED and notify the list
... the list needs to be notified at some point
... to inform people that the changes have been taken into account

<dom> (I think fixing the draft first makes it clearer)

AnssiK: so there's no preference in the group

darobin: i have a preference for not having a discussion about commit-then-review or review-then-commit
... because i have had that discussion too many times recently

+1

AnssiK: we can always revert

Contacts

fjh: rich sent a message to the list saying he was doing more for it
... [looks for message]

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0107.html

fjh: he's going to respond to the feedback
... maybe we should wait for rich's input on this... instead of rehashing it twice
... in terms of discussions about implementation
... and use cases

<fjh> https://bugs.webkit.org/show_bug.cgi?id=63223

fjh: I noticed that the WebKit team was asking for justification to have this implemented
... dom: if you had use cases, it might be helpful
... at least to try a use cases discussion

<dom> My use cases for Contacts API

darobin: we should be able to provide an argument in favor of implementing our specifications
... otherwise i don't know why we're writing them in the first place
... I believe josh's feedback was integrated by dom

<dom> (only the editorial feedback; not sure if Josh also sent substantive feedback)

<Zakim> jsoref, you wanted to comment on that

My non editorial items were not integrated

scribe: I'm assuming that rich will address them

darobin: back to LC tracking
... i guess that's something we can do right before the f2f
... i presume, dom, that you won't be around to put it together
... one thing that we could do is the LC tracking system
... fjh i think it's the one you were using for XMLSEC WG

fjh: you it works fine

darobin: do we need to do something to open new specs in it?

dom: i can take care of that
... but the question is who takes care of it after

<dom> ACTION: Dom to open a Last Call comments tracker for Contacts API [recorded in http://www.w3.org/2011/06/29-dap-minutes.html#action03]

<trackbot> Created ACTION-419 - Open a Last Call comments tracker for Contacts API [on Dominique Hazaël-Massieux - due 2011-07-06].

darobin: if the team side sets up the documents and we can do the rest
... and the chairs can take care of the comments, since there aren't many

Network information api feedback

darobin: i think we're stuck on feedback, including mine
... i have an action to reply to feedback
... that's entirely in my court

[ I need to give feedback ]

darobin: are there other items?
... is there anything people would like to prioritize for the f2f
... it's coming up in a few weeks
... if you have topics
... you can send feedback to the list / chairs

ADJOURNED