[1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

          Device APIs and Policy Working Group Teleconference

29 Jun 2011

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0091.html

   See also: [3]IRC log

      [3] http://www.w3.org/2011/06/29-dap-irc

Attendees

   Present
          Kihong_Kwon, Robin_Berjon, Frederick_Hirsch, Josh_Soref,
          Dominique_Hazael-Massieux, Laszlo_Gombos, Anssi_Kostiainen,
          Cathy_Chan, Cecile_Marc, Niklas_Widell, Wonsuk_Lee,
          Kangchan_Lee

   Regrets
          Suresh_Chitturi, Wonsuk_Lee, Rich_Tibbett, Ernesto_Jimenez,
          Dzung_Tran

   Chair
          Robin_Berjon, Frederick_Hirsch

   Scribe
          Josh_Soref

Contents

     * [4]Topics
         1. [5]Administrative
         2. [6]Minutes approval
         3. [7]Charter
         4. [8]Battery Specification
         5. [9]Contacts
         6. [10]Network information api feedback
     * [11]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 29 June 2011

   <scribe> ScribeNick: jsoref

   <scribe> Scribe: Josh_Soref

   <lgombos> Zakim: Present+ Laszlo_Gombos

   fjh: First topic is administrative

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

     [12] http://lists.w3.org/Archives/Member/member-device-apis/2011Apr/0000.html

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

     [13] http://www.w3.org/2002/09/wbs/43696/paris-2011/

Administrative

   <fjh> Publishing moratorium 24-29 July

   <fjh>
   [14]http://lists.w3.org/Archives/Member/member-device-apis/2011Jun/0
   011.html

     [14] 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>
   [15]http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/a
   tt-0055/minutes-2011-06-15.html

     [15] 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
   [16]http://www.w3.org/2002/09/wbs/33280/dap-2/results

     [16] 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> [17]Robin's review of other platform battery APIs

     [17] http://lists.w3.org/Archives/Public/public-device-apis/2011May/0043.html

   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
   [18]http://www.w3.org/2009/dap/track/issues/112/edit .

     [18] 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
   [19]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
   [20]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>
   [21]http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0
   107.html

     [21] 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> [22]https://bugs.webkit.org/show_bug.cgi?id=63223

     [22] 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> [23]My use cases for Contacts API

     [23] http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0109.html

   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
   [24]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

Summary of Action Items

   [NEW] ACTION: Anssi to implement changes to battery event based on
   feedback, and RESOLUTION from 20110629 [recorded in
   [25]http://www.w3.org/2011/06/29-dap-minutes.html#action01]
   [NEW] ACTION: Dom to open a Last Call comments tracker for Contacts
   API [recorded in
   [26]http://www.w3.org/2011/06/29-dap-minutes.html#action03]
   [NEW] 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
   [27]http://www.w3.org/2011/06/29-dap-minutes.html#action02]

   [End of minutes]