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

Sensor API

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

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: 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"

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

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