See also: IRC log
<trackbot> Date: 04 April 2012
<scribe> Scribe: Josh_Soref
<fjh> Web Application Store Community Group Launched: http://lists.w3.org/Archives/Public/public-device-apis/2012Apr/0003.html
fjh: we aren't ready to approve them
<fjh> Draft F2F Minutes (and notes of items in minutes requiring correction): http://lists.w3.org/Archives/Public/public-device-apis/2012Apr/0004.html
fjh: I doubt we'll be able to approve them next week
... there's a lot of them
... please look at them
<fjh> please review and provide corrections to josh and public list
fjh: the topic has come up as how/where/when should it be chartered
<fjh> https://lists.w3.org/Archives/Member/w3c-ac-members/2012JanMar/0057.html
<fjh> Please have any chartering discussion on AC forum list (member only), see also https://lists.w3.org/Archives/Member/w3c-ac-forum/2012AprJun/0000.html
fjh: I don't think it's appropriate for our WG to get into the nitty gritty of chartering
... you can have your AC rep get involved
... I don't think it has anything to do with technical merit
dsr: I had some discussions
... I followed up with ArtB
... there's some informal discussion in various places
... I'm trying to reach out to various people
fjh: I think what we started to do at the F2F
<darobin> [I think I should point out that the WG can decide to discuss its charter in public if it so wishes — if you look at the beginning of http://lists.w3.org/Archives/Public/public-device-apis/ that's in fact how the first charter was elaborated]
<fjh> List discussion following CfC, http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0222.html
<darobin> [just be careful in using information you may have obtained through privileged channels in doing so]
fjh: I want to leave it to AC reps + Team
... I don't want to step into it
<dsr> I am reaching out to people directly to clarify their interests/concerns, we may have discussion relating to use cases, scope on public list, and some people have suggested that a community group may be appropriate to discuss this further.
fjh: we had a CfC
... we talked about eliminating that spec
... there's been a lot of discussion on the list
... some people have asked if we can stop the discussion
... I don't think we can/should
... it's been good
... there's concern about doing things in a blanket fashion
... where we're really ending up is that we need to look at each sensor
... and how to package it
... there's a useful discussion happening
... we need to look into thresholds/watchpoints
... I don't think we can resolve anything on this call
... if you haven't looked at the discussion on the list, you should
... what I'd like to do is figure out what we can do on the list
... and then decide what to publish
<Zakim> bryan, you wanted to note that I will be capturing the list discussion on the wiki, and I recommend that we hold off making a decision for the overall threads of argument to be
<fjh> +1 agree to capture arguments, understand issues, then decide re CfC
dtran: I don't know if it's useful or not to do a quick edit of the current spec
fjh: my take is that if there's anything concrete, you can move forward
... the wiki is good
... if you're able to do an edit that's easy and helps us move forward, then yes
... imo, anything we can do that's concrete and helps us move forward is good
... but you need to make a judgement about how much work you want to do
dtran: ok
... I think the mozilla people [garbled]
... I think something simple
... the mozilla guys want something simple for javascript programmers
... I can put an outline together and send it out
fjh: if anyone on the call has concerns, please speak up
... bryan: do you have further plans to work on the wiki?
bryan: well yeah, it was intended to be collaboratively edited
... I will try to capture the thread from the mail list to the wiki
... it's just there as a template
fjh: I think you have to ask the wiki to be notified
... so if you, bryan, could send out a notice to the list summarizing big updates
... that'd be good
bryan: it's going to take a bit of time to work through the issues, to get the architecture right, and we shouldn't rush
fjh: I agree
[ random beeps on the line ]
<dtran> maybe I just edit the Wiki instead?
fjh: we want to avoid rework
<Zakim> bryan, you wanted to ask (back on the sensors topic), if we can get info from the existing implementations sent to the DAP list and/or put into the wiki, related to the questions
bryan: if we could get people to gather information relating to implementations that already work
... privacy, parameter design, what the share, ...
... I'll send a request to the list
fjh: right, that will be helpful
... what I try to do for a call is use the list as input for a call
... and not do things on the call without drive from the list
<fjh> Network Information API was landed on the Webkit, http://lists.w3.org/Archives/Public/public-device-apis/2012Apr/0002.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0219.html
fjh: dom raised some concern
... I didn't get what dom was saying
... I think he was saying you have a whole stack and it depends on the whole stack
<bryan> It will take couple of weeks to capture discussions. I will update the wiki as I see significant new info. We are talking about fundamental API design approaches here, and I recommend that we take out time to do so. This is analogous to the time it took for us to course-correct from programmatic APIs to markup-based APIs (though in this case it should not take *that* long, and in that case we have subsequently waffled on the original course
<bryan> correction)
[ we can't hear AnssiK ]
[ AnssiK calls in -- now with Voice ]
AnssiK: you asked about dom's message
... in the cellular radio, there are a couple of power states
... when you are actively sending data over the radio, it costs much more power than when it's idle
... so if you can inform applications when the radio is already up
... for example if the user is browsing the web
... then the web app can try to use the radio concurrently
... an event exposed to developers, similar to the online event
... saying "now the radio is actually up"
<bryan> Last email on the list related to what Anssi is talking about: http://lists.w3.org/Archives/Public/public-device-apis/2012Mar/0221.html
<fjh> radio on/off events exposed?
AnssiK: so all apps get a notice "the radio is up"
... and then respond to it and do their work during this window
fjh: there's a lead time for the radio going on
... and a window when it's on
AnssiK: this is a message bus kind of thing
... you can be clever re: when to use the resources
... this is ideal for background situations
<bryan> Dom started that thread based upon noting the AT&T work on network connection use optimization http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=Jzq2QAkHxoP
<fjh> sounds sort of like cooperative-multitasking, maybe has similiar issues?
AnssiK: like twitter updates/email client updates
... I'm thinking of a way to do it like offline
bryan: there is a thread on the list about this
... I think something would be a good thing
... I don't know how complicated it would be in the end for developers
... to effectively respond to that information
... maybe even the APN for the app could vary?
... experience would help us learn what the risks of that information
... and maybe libraries would develop
... it's definitely worthwhile to think about that
... but maybe more precise than simple online
<Zakim> Josh_Soref, you wanted to say that the time slices are too fast for this
Josh_Soref: the radio goes on and off fast
... radio can go on and off really fast, much faster than javascript app can respond, app needs to be waiting when getting event
bryan: we don't think it goes so fast in our analysis
... not order of ms
Josh_Soref: enable apps to make requests, queue them, have sent when it makes sense
<bryan> the state changes don't happen on the order of MS, usually a few seconds for the transient states - see the referenced research work from AT&T
Josh_Soref: that would simplify things for app developer
bryan: we're looking into cooperative network usage
... cooperative multithreading
... bundling of network requests
... that work is being discussed in OMA
... if we want to go there in W3C
... we're going to need the information that dom suggested
... and that AnssiK echoed
fjh: I wonder if this api is bigger
... it seems like it has a lot of implementaton implications
... we should take this to the list
<bryan> we are beginning related work in OMA on bundling/scheduling of network transactions for efficiency - that work if it comes to W3C in some form would need the network state info described here (if that info wasn't just something known by a lower-layer native implementation of some API exposed to the webapp)
<AnssiK> the API itself could be modeled on http://dev.w3.org/html5/spec/offline.html#browser-state
fjh: I think it assumes a certain architecture behind it
<bryan> the overall objective of the OMA work I mentioned is to help address the network resource efficiency of having multiple always-on apps, that may not need immediate fulfillment of a network request, or a distinct network connection to deliver it.
fjh: please review the F2F minutes
... send comments to josh and the list
... anything else?
Josh_Soref: next week runs into some people's vacations
fjh: I know I have a vacation the following week
Josh_Soref: next week is Passover, but I'll be in
<bryan> The Tracking Protection WG meeting in DC is next week.
fjh: if we have many regrets, we'll cancel
... or we could cancel if there's nothing to discuss
... I'll talk with darobin
<darobin> [we can make that decision on Tuesday]
Josh_Soref: there was supposed to be a Web Apps meeting next week, but they moved it out because they didn't get a venue
[ adjourned ]
trackbot, end meeting