See also: IRC log
<trackbot> Date: 09 May 2012
<scribe> Scribe: Josh_Soref
<fjh> CR of Battery API published
<fjh> CR of Vibration API published
fjh: thanks AnssiK, mounir
<fjh> NFC WG chartering
fjh: that's a message from dsr about NFC WG chartering
dsr: darobin and I have been working on System Level APIs charter
... we hope to have both charters up for review at the same time
... we need to fill in some dates in them to complete them
<fjh> System Level Charter email
fjh: do you have a deadline for them?
dsr: we'd like to get them done ASAP
fjh: I noticed NFC was mentioned in the System Level API
... I'm not sure that's appropriate
dsr: AC review is a good way to get feedback
... [ it can be removed then ]
<fjh> DAP Welcome to new members
<fjh> Yosuke Funahashi, Doug Turner, Mahesh Kulkarni, Cuihtlauac Alvarado, and Milan Patel
<fjh> Paul Liu Feng and Eduardo Fullea Carrera
fjh: if you're new and want to introduce yourself, now is a good time
... but please also introduce yourselves on the list
<fjh> Approve minutes from 25 April
<fjh> Minutes from 25 April
RESOLUTION: minutes from 25 April are approved
fjh: we have agreed for July 10-12
... we have offers from Nokia, Burlington
... and Vodafone, Dusseldorf, Germany
... I think we need to decide this week
<fjh> Next F2F 10-12 July 2012.
<fjh> Hosting offers (1) Burlington MA US (Nokia), (2) Dusseldorf, Germany (Vodafone)
Josh_Soref: I was hoping we'd have a decision today :)
milan: being in Europe, I have a preference for Europe
Cathy: I'll note that TPAC is in Europe as well
... so it might be better to do it in US
fjh: We could do a survey
... darobin is ok either way
dsr: unless you hear strong objections
... it's up to you
fjh: proposed resolution to meet in burlington
nwidell: I'd prefer to have it in Europe
... it's the middle of vacations in Scandinavia
... so it's easier to get to
fjh: I think it'll be easier for some to get to Burlington
RESOLUTION: F2F meeting July 10-12 in Burlington
fjh: thanks dsr
... sorry nwidell
... I understand your concern
fjh: AnssiK, I know you put together a draft
<fjh> Device light and proximity sensor
fjh: I know wonsuk updated his draft
... talking about proximity
<dtran> I have updated the Sensor API also
fjh: I noticed it's essentially the same as wonsuk's
... your draft seems more detailed than wonsuk's
... I don't understand min/max
... it seems like it'd be constant for a sensor
dtran: I was editing sensor API for a while
... I updated the API to have the same signature as dougt suggested
... min/max are pretty much constant for all sensors
... I don't know if we could make them separate attributes
... now you get the same value every time
... min/max are constant
fjh: min/max are constant for a given sensor, which is what I'd expect
... I noticed that AnssiK supported separate specs
... it's also easier for testing and moving specs forward
... to have separate specs
... packaging concerns as AnssiK mentioned, we can pull out later
dtran: the sensor spec says it's optional to implement sensors
... it's up to a UA to decide what to implement
... we could rip them out one by one
... I just don't like having lots of specs that look all the same
fjh: I understand
... but having optional things
... getting interop is harder
... editorial task of one/two docs can be handled later
... we need to focus on implementations now
AnssiK: I think fjh has said what I wanted to say
... small self contained features/specs progress on REC track better
... some things that are common to all sensors
... it's much easier to work on the right design with one sensor first
... and then progress with others
... I think security/privacy considerations should be taken seriously for all sensors
... if we work on sensors separately, the likely that security/privacy is properly scrutinized increases
... I'm happy to work with others to make it happen properly
... I want to get other implementers interested
... an all in one spec may scare away implementers
... I'd like to ask for an opinion
... all-in-one, or one-by-one
<AnssiK> [sensors] Device Proximity (was: Device light and proximity sensor)
AnssiK: in my mail, I had my arguments
... it would be better to reply to my mail on the list
... thanks
bryan: those are all sensible arguments
... I had concerns in the past with documentation in multiple specs
... on technical aspect
... maybe I can send to the list again
... does the group think it's not necessary to have trigger points/rate of events?
... that those things will be discovered by the app in a consistent/interoperable way
... will it not be a burden to discover trigger point/rate of events?
... is it good enough to have min/max
... and the other stuff will be figured out over time
dtran: that's the problem with dougt's proposal
... I work with sensors every day
... and you don't get information about trigger points
bryan: I like the simplicity of the current proposal
... my preference is
... ultimately, whatever makes it easiest for implementers
... we need to take into account that Intel is an implementer
<fjh> my point is that to progress a spec we need interop on optional features, so having more in the spec makes it harder to progress
<Zakim> dsr, you wanted to ask about differences between dougt's and dtran's API
dtran: I'd suggest you bring it up on the ML
... there's a thread on the HTML5/WhatWG ML
... I don't know how we can bring it back
fjh: I think bryan said he'd send an email about this
<dsr> dougt's proximity example: http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/ and dtran's http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html, AnssI's http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html
dsr: there were some differences
... in dougt's proposal, he used window.eventlistener callback
... dtran's is different
... and AnssiK's is similar to dougt's
AnssiK: I looked at dougt's implementation and spec'd it out
... I don't have a position at this point
... I think it's easier to make progress if I write down what dougt implemented
... and then make progress concurrently wit implementations
<fjh> makes sense to me
AnssiK: I don't know about dtran's proposal
dtran: previously the sensor spec
... allowed you to set threshold/rate of the sensor
... to report back to you
... I also updated my spec to be like dougt's
<dsr> Dave: Dzung's spec of May 8th uses different design from Doug and Anssi, which do we want to take further?
dtran: I see AnssiK also did a separate spec
... we can have a discussion with dougt
... and update it to have features that I had
... I think that would be the approach
... I have some ideas how to do that
dsr: another question
... the whatwg list
... noted that if you don't have a sensor, or do have a sensor
... you shouldn't be able to detect if a sensor is present
dtran: that's sensor discovery
... the WG decided not to have Sensor Discovery for privacy/fingerprint reasons
... that's why it was ripped out from the old spec
... we had that discussion many months ago
AnssiK: I took a similar design to the Battery status
... if the implementation can't report something
... I report a default value
... I looked at dougt's code
... and it assumed that it was always available
... that was something I added on top of dougt's spec to make it more complete
... it's something we need to flesh out in the group
... assuming this proposal is taken
... I don't have a hidden agenda here
... I just want to make the web kick ass on devices
... I'm happy to work with others, dougt, and dtran, etc.
<Zakim> nwidell, you wanted to ask about sensor discovery with web intents
AnssiK: I just want to move forward and get the work done
nwidell: we discussed discovery a long time ago
... some wanted JS and some wanted WebIntents
... I really liked dougt's proposal which is very simple
... is there a nice way to tie together WebIntents with this DOM Event based sensor events?
... I haven't really figured that out
... can what is returned from WebIntents show up as a DOM Event in the caller?
dsr: that's valuable feedback to the WebIntent ML
... if you have remote-sensors, we'd like to be able to unify them
<fjh> interesting how webintents is considering sso/login as well
Josh_Soref: could have wrapper to generate DOM event, currently WebIntents does not do on its own
<Jungkee> The Gallery API
<fjh> Gallery API draft review request
Jungkee: I had feedback from richt, bryan, and dougt
... the idea is to use WebIntents to locate galleries
... and access video/audio + metadata
... using intents callback
fjh: I think there was some concern about Size on the list
Jungkee: yes, I am now writing sample code
... I can probably share the demo code somewhere
... was discussed in an email thread
... I'd like to hear more from members here
... I can now update with more
... for which way of data delivery
... service providers can also
... interact
fjh: will you send out an email about this with a summary
Jungkee: for sure
fjh: thank you very much
fjh: I don't think we need to talk about this
<fjh> Updated draft
<fjh> Move to Notification WG
fjh: I don't think anything needs to be done
... lgombos, maybe you can follow up with the Notification WG
AnssiK: dtran agreed to be an editor for Proximity
... thanks dtran
fjh: anything else to discuss?
dsr: AC meeting next week
... Phillipp Hoschka is leading a talk about
... Towards a Web Platform - that provides all that is needed for Mobile Apps, and I will be covering the part that deals with system/browser safe APIs including NFC and Bluetooth. I am more generally inviting anyone on DAP to pass on any questions/concerns for the AC meeting.
bryan: one other thing
... in webapps f2f, there was a good
... discussion on test methodology
... test assertion
... there was a consensus on taking a tooling approach
... over a metadata approach
... definitely with these two specs that have reached CR
... want to help the test suite
fjh: there's a Media Capture call today
<Zakim> Josh_Soref, you wanted to comment on webapps minutes
Josh_Soref: I'll try to get webapps f2f minutes today
... and html-wg tomorrow
... with minutes from today's calls (DAP + MC) later
fjh: thanks everyone
... thanks Josh_Soref for scribing
[ Adjourned ]
trackbot, end meeting