See also: IRC log
<trackbot> Date: 12 December 2012
<scribe> scribe: Josh_Soref
<fjh> Network Information API updated draft published: http://www.w3.org/News/2012#entry-9640
<fjh> Proximity API Last Call publication planned for tomorrow.
<fjh> Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0039.html
<fjh> Last Call of "Proximity Events" published, comments through 24 January - http://www.w3.org/TR/2012/WD-proximity-20121206/
<dom> [I think we should also discuss https://www.w3.org/2002/09/wbs/43696/f2fQ12013/results since the questionnaire is now closed]
<fjh> (news announcement: http://www.w3.org/News/2012#entry-9649 )
<fjh> Reminder - no teleconference 19 December, 26 December, 2 January. Next call 9 January 2013.
<fjh> 28 November 2012 - http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/att-0005/minutes-2012-11-28.html
<fjh> proposed RESOLUTION: Draft minutes from 28 November 2012 are approved.
RESOLUTION: Draft minutes from 28 November 2012 are approved.
fjh: let's resolve that last week's minutes are approved as well
RESOLUTION: Draft minutes from 5 December 2012 are approved.
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0042.html
fjh: we have a new updated draft
... reflecting the capture attribute
<AnssiK> HTML Media Capture
fjh: we have an updated draft
... i want to agree to publish it today
<fjh> proposed RESOLUTION: The WG agrees to publish an updated Working Draft of "HTML Media Capture" on 13 December 2012
fjh: if we don't publish it today, we hit the moratorium which takes us into January
<dom> +1 on updated WD
<AnssiK> +1 to publish
Josh_Soref: +1 to publish
RESOLUTION: The WG agrees to publish an updated Working Draft of "HTML Media Capture" on 13 December 2012
<fjh> ACTION: fjh to send publication request for HTML Media Capture [recorded in http://www.w3.org/2012/12/12-dap-minutes.html#action01]
<trackbot> Created ACTION-603 - Send publication request for HTML Media Capture [on Frederick Hirsch - due 2012-12-19].
fjh: thanks AnssiK for your work on this
<fjh> https://www.w3.org/2002/09/wbs/43696/f2fQ12013/results
<dom> Results of survey for picking date for next F2F
fjh: looks like Mar 4-8 is promising
dom: it looks like Apr 8-12 is preferred
fjh: it isn't the best for me
... is there any possibility of doing it not the #1 choice?
... there's a problem for me that week
dom: Mar 4-8 is annoying to 6 people
fjh: i can't meet on Friday
Josh_Soref: don't we usually only meet 3 days anyway?
fjh: how many days do we meet?
dom: usually 2.5
fjh: could we do Mon-Wed ?
... i think it depends on where we're hosting?
Milan_Patel: do we have material for more than 2 days?
fjh: why don't we plan on 2 days?
dom: the problem is that people tend to leave early on the last day
... cutting time shorter
fjh: i'd have to return on the Wednesday
dom: let's say Apr 9-10
fjh: does anyone know if they can host?
<fjh> proposed RESOLUTION: next F2F will be held 9-10 April 2013
fjh: i'll send out a request for hosts
... i need to get back on thursday
RESOLUTION: next F2F will be held 9-10 April 2013
<fjh> I will need to return on Thursday, so need to end Wed
<fjh> ACTION: fjh to request offers of hosting [recorded in http://www.w3.org/2012/12/12-dap-minutes.html#action02]
<trackbot> Created ACTION-604 - Request offers of hosting [on Frederick Hirsch - due 2012-12-19].
fjh: we were thinking Europe
... but it depends on who can host
... anything else on this topic? any volunteers to host?
<fjh> Visibility into radio status? http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0012.html (Bryan)
fjh: bryan, should we talk about this today?
... or on the list?
bryan: let's carry on the list
dom: i've seen this notion of being able to react to the radio state
... brought up a number of times
... it was also brought up in Web Performance
... i think it's something fairly important and useful on mobile devices
... independently of Network Information API
... i think it would be very good
... we need to know whether anyone is interested in doing something in that space
... i think there are performance and battery benefits to be gained from that approach
fjh: bryan, i think your message outlined the rationale
gmandyam: i tend to agree w/ nwidell 's message
... radio state can be useful for power consumption
... i think it's less useful for connectivity/bandwidth
... taking it back to a Web Performance Workshop
... I had a paper on keep-alive for a web socket connection
... the web structure isn't designed to map well to radio connections
... mapping full radio state to the browser is probably not useful, even detrimental
fjh: i was thinking of a higher level
nwidell: i'm of similar thinking as gmandyam
... radio state
... i don't know if we can
... i think it's pretty difficult for this to work out
... this information is hard to work with/to understand
... if every web developer must understand this information
... to make use of it
... i don't know if it would be very good
<dom> [I think exposing it via grouping network requests or setting priority would work best, indeed]
nwidell: which is why i think it should be done by the browser
... maybe a queuing mechanism done by the browser
... but not exposing the details to the application
Josh_Soref: +1 to favor queuing
fjh: we had that discussed at a F2F
dom: i think it's easier to discuss concrete proposals
<fjh> need implementer feedback
dom: i agree we need something at a higher level than radio state
<fjh> generally +1 to higher level approach
nwidell: i think it would be very good
... if we could try to figure out
... what developer problems
... what information they would like to have
... what information they'd have use for
... i tried to look into this
... it's very difficult to figure out what UCs we're trying to solve
... also to address adrianba's comment at TPAC
... big players/small players
<Zakim> Josh_Soref, you wanted to +1 nwidell 's call for UCs
Josh_Soref: 1. need use cases
... 2. need facts of radio behaviour
bryan: i think UCs are fine
... if it would help to explain the type of things we're trying to seek advantage from
... there are plenty of papers we could reference
... i suggest we continue the discussion on the list
... i don't see problems as nwidell sees
... i think we need to talk about the problem of JS libraries v. deferring behavior to the browser
... those are two different approaches
fjh: i agree this should go to the list
... i think we need to work this through
fjh: our next call is Jan 9, 2013
... i'd like to wish everyone a Merry Christmas, Happy Hannukah, Happy New Year, whatever else
... and we can use the list for anything else that comes up
nwidell: has there been any update on Web Intents at all?
... there was a message from greg
fjh: no
... i need to follow up
... thanks everyone for their time
trackbot, end meeting