<dom> ScribeNick: kenneth_

Agenda of today is wakelock and generic sensors api, and a bit of media capture

<dom> https://github.com/dontcallmedom/github-notify-ml/

RESOLUTION: Minutes from 23 February 2017 are approved https://lists.w3.org/Archives/Public/public-device-apis/2017Feb/att-0010/minutes-2017-02-23.html

Wake Lock API

incorporated all TAG feedback to the spec

planning implementation but hasnt started it yet

Moving onto sensor discussions

Sensors

Concerns around permission API

<dom> https://github.com/w3c/sensors/issues/174

<dom> https://github.com/w3c/accelerometer/issues/4

1. Chrome considers that they want oto ship the specced stuff without permissions (Owen)

Security feedback are concerned about this

If other vendors ship behind permissions this will not be interoperable

<dom> Tobie's view on auto-granted permissions

we can keep permissions in place and Chrome can auto grant

Then this becomes an implmentation point, not a spec one

One of hte mitigation strategies in place to hopefully avoid the security concerns with motion sensors is to limit polling frequency

security concerns are around sniffing people entering passwords etc on a table together with another phone which is using sensors

with machine learning these becomes bigger concerns

idea was suggested to limit to 60hz

which breaks some use-cases we have

and it is not a real migitation strategy anyway

doesnt solve issues but means that VR etc cannot function

<dom> Tobie's view on high frequency polling

anssik_: might want ot auto grant for low frequencies, could be an option

shalamov: (misha) hard to provide a good prompt and get the user to understand and make the right decision

tobie: I agree

mikhail: we are tying to better find out how this affects when frequences are > 60hz

tobie: prompting the user is very concerting because it is very hard to explain what the problem is
... the permission spec was designed with all of this in mind

like you dont necessarily need to prompt a user

I agree it is a very hard problem

mikhail: I believe the same frequency is exposed via DeviceMotion spec

tobie: good point, but we are changing api and are probably providing deeper access, so the end goal is to get rid of (deprecate) device orientation/motion

dom: we shouldn't stop fixing things because it is broken to begin with
... the idea of using permission spec is that we decouple ourselves from how the prompting should be done

we dont want to get into this discussion

dom: what is the plans for the next steps

tobie: anssi wants CR, but I want research done for motion sensors to be documented before

this is drifting into motion sensor discussions

motion sensors have different requerements and characteristics

It makes sense to have them as a subclass of generic sensors

should there be a motion sensor / high frequency sensor subclass

how to deal with ambient light etc, evented sensor?

lots of discussions needing more research

maybe add more in generic sensors

or move these new super class into a dedicated spec

gutfeeling for now is that we sould think of these as high frequencies instead of motion sensors... but might be a dumb idea :)

when we have more info we will have more clarify to what to do next

a massive open issues inlines in the spec itself

dom: short story, not there yet

<dom> Level 1 issues on Generic Sensors

tobie need to spec integration with RAF etc

tobie: that is my focus over next weeks

anssik: tobie can you confirm that the milestone labels still make sense

tobie: yes, hopefully pretty much yes :)
... I think high frequncy might bring more into level 1

otehr option is to do CR now and then push it into level 2

but we dont have a second implementation

tobie: I need to check if I have to move stuff, milestones etc... (some stuff to do)

<dom> ACTION: Tobie to update milestones on Generic Sensor issues [recorded in http://www.w3.org/2017/03/09-dap-irc]

<trackbot> Created ACTION-785 - Update milestones on generic sensor issues [on Tobie Langel - due 2017-03-16].

<dom> [we could use a github project dashboard https://help.github.com/articles/about-projects/ ]

tobie: rant about github issues... hard to see what is a 6 month work or a 2 hour work item

<anssik> see e.g. https://github.com/w3c/strategy/projects/2

Motion Sensors

<scribe> new repo for orientation spec

threads for unique motions spec

Kenneths proposal for an explainer how they work and relate

what devs and users need to understand in that space

<anssik> https://sensor-compass.appspot.com/explainer.html

dom: lets discuss explainer and discuss mechanics of that

then touch other topics

we could adopt this as part of work item

as a simple starting point

create a repository to host it

anyone has thing to share about this

<dom> kenneth: the whole motion sensors area is not well documented anywhere; there aren't good books or articles on this

<dom> ... I personally had a lot of troubles when having to build demos, around filters, combinations, etc

<dom> ... base sensors / fusion sensions / Make-Your-Own-Sensor

<dom> ... we should try to explain this in a way that developers outreach can be done effectively

<dom> ... showing lots of good examples will help also identify the good, the bad and the ugly in our API

<dom> ... e.g. I identified the potential need of getting time differences rather than timestamps

<dom> anssi: sounds like a great document to have; didn't anticipate it would materialize so fast!

<dom> ... +1 on kenneth

<dom> ... we've been catering mainly for implementors, the specs don't provide much background around the technical implementation bits

<dom> ... this is a great complement to that

<dom> ... and it definitely fits in our charter

<dom> ... we should move it to the w3c github account

<dom> ... I would support adopting this as a work item

<dom> kenneth_: this actually was one of the problems with the old device orientation spec, leading to non-interoperable implementations

<dom> ... exposing low level sensors helps when fusion sensors don't match your use case

<dom> https://github.com/w3c/motion-sensors/ created

<dom> dom: at some point we'll need to decide how to publish that doc: just an editors draft, a WG note, introductory to a Rec track doc. no need to decide today, but any early input on this?

<dom> tobie: I shared my perspective on the list that we should merge all motion specs in one doc and have this as an intro

<dom> ... an integrated document makes it easier to find for developers

<dom> kenneth: I fear that a separate note is less easy to discover for devs

<dom> anssik: at the minimum the document should be tightly cross-linked from specs

<anssik> https://lists.w3.org/Archives/Public/public-device-apis/2017Mar/0001.html

<dom> ... I think you often to compromise between catering for devs vs catering for implementors

<dom> ACTION: Kenneth to import motion sensors explainer in https://github.com/w3c/motion-sensors/ [recorded in http://www.w3.org/2017/03/09-dap-irc]

<trackbot> Created ACTION-786 - Import motion sensors explainer in https://github.com/w3c/motion-sensors/ [on Kenneth Christiansen - due 2017-03-16].

<dom> anssik: my preference is to keep the current structure, but will follow the group's consensus; no rush in changing in any case

<dom> tobie: what demands attention right now is research on the sensors, use cases and requirements

<dom> ... for motion / high frequency sensors

<dom> ... once we have more stuff around this, it will make it easier

https://w3c.github.io/motion-sensors/explainer.html

<dom> ... that said, "explainers + normative stuff not going well together" - I don't necessarily agree with that as a general rule of thumb

<dom> ... and in this case, where there is a lot of domain specific knowledge, it's important that implementors understand the surrounding requirements to implement the right thing

<dom> ... that might point to things that aren't clear enough in normative content

<dom> ... but I still think you can't really decide what you're going to explose in a sensor fusion if you don't understand the associated trade-offs

<dom> shalamov: we've introduced this new motion sensor draft, built on top of 3 low level motion sensors

<anssik> https://w3c.github.io/orientation-sensor/

<dom> ... it's exposing quaternions & WebGL compatible rotation matrices

https://w3c.github.io/motion-sensors/ works now btw

<dom> ... will use this as an early spec for implementation in Chromium

<dom> Tobie: I've made a number of comments on this in pull requests and issues

<dom> ... it's great to see more experimentation work, but not quite sure it's the right direction quite yet

HTML media capture

<dom> Anssi: spec sitting in CR, renewed interest in implementors (questions from Google & Apple)

<dom> ... crafted an update to the spec to move it to an enum

<anssik> https://w3c.github.io/html-media-capture/

<dom> ... reviewed by implementors

<anssik> https://crbug.com/698853

<dom> tobie: ♥ moving this forward

Battery

<anssik> https://github.com/w3c/battery/issues/9

<dom> Anssi: Chrome still shipping it

<dom> close ACTION-786

<trackbot> Closed ACTION-786.

<dom> ... issue 9 is an interesting proposal to reduce privacy surface with a new feature detecting "low battery mode" as set by the user

This is scribe.perl Revision: 1.147  of Date: 2016/03/23 18:03:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_HTML_Format (score 0.99)

Succeeded: s/feedback/TAG feedback/
Succeeded: s/impl/implementation/
Succeeded: s/autogrand/auto grant/
Succeeded: s/shalamov/mikhail/
Found ScribeNick: kenneth_
Inferring Scribes: kenneth_
Present: Andrey_Logvinov Anssi Kenneth Tobie_Langel Mikhail_Pozdnyakov Alexander_Shalamov
Regrets: Frederick
Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2017Mar/0007.html
Found Date: 09 Mar 2017
People with action items: kenneth tobie

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.