Device APIs Working Group Teleconference -- 28 Nov 2012

<trackbot> Date: 28 November 2012

<gmandyam> Giri Mandyam from QuIC on the call

<scribe> scribe: Josh_Soref

Administrative

<fjh> Staff contact change - Dom is now staff contact - http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0036.html

<fjh> fjh: Again thanks to both Dave and Dom for their work with DAP.

Josh_Soref: I sent fjh draft minutes from the F2F
... he'll publish them

<fjh> fjh: End of year publishing moratorium, no publications 14 December 2012 - 2 January 2013: https://lists.w3.org/Archives/Member/member-device-apis/2012May/0000.html

<fjh> No teleconference 19 December, 26 December.

<dom> +1 on cancelling on Jan 2nd

RESOLUTION: Call on Jan 2nd is canceled

fjh: i might have trouble with the call on 12 December

dom: i could probably chair if needed

fjh: i'll work to ensure we have an agenda

Minutes Approval

fjh: i'm relatively informal about meeting agenda
... preferably, please let us know at the beginning of the call
... F2F minutes should go out shortly

<fjh> Draft minutes from 14 November for approval: http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/att-0031/minutes-2012-11-14.html

fjh: thanks Josh_Soref

RESOLUTION: Draft minutes from 14 November 2012 approved.

Network Information API

fjh: i'm working with mounir to publish the updated draft
... after I made the pub-request, i found a new link error
... i'm sure dom can help us work it out
... i expect to publish tomorrow or tuesday
... mounir is figuring out the link

HTML Media Capture

fjh: there's been a bunch of editorial updates
... i've been discussing with tobie on the list
... and Josh_Soref jumped in
... I think tobie and i are in agreement
... let's see if i understand
... you have the <form> <input> element
... you do capture
... it doesn't actually upload the image
... to the web server
... you get the handle?

<gmandyam> Have a question on Network Info API

gmandyam: i think i'm a little frustrated because we're not making any attempts to solve estimation of bandwidth
... there's nothing in the spec
... and it's acknowledged that it's hard to do
... what the browser is returning isn't what the modem is returning
... i'm not happy about moving the spec forward
... to FPWD
... and having Call For Exclusions

<dom> [network-info has already gone to FPWD]

fjh: we aren't moving to FPWD
... we're updating an out of date draft
... it's already published

gmandyam: it's an unusable spec as it stands

fjh: the WG already decided to publish
... a WD is a draft, it's subject to change
... it doesn't mean that we can't make changes
... there's a Call for Exclusion on FPWD and LC
... but not updated drafts

dom: there won't be a Call for Exclusion on an updated WD

fjh: we're just trying to get the draft to reflect our current state

gmandyam: i'll take my concern to the list
... thanks

fjh: there are issues noted in the doc

Josh_Soref: which issue tracker are we using?

dom: we're using Tracker, or we were when I was last the staff contact

fjh: we could put an issue in now
... if you put an issue on the list, you or i can raise it to tracker
... gmandyam, it'd be preferable if you put in a proposed resolution
... you can also go into tracker and collate it
... i have instructions on...
... i have a link here

<fjh> link for practice to enter issues - https://www.w3.org/2008/xmlsec/Group/Overview.html#issues

fjh: that has the process for raising issues
... i got it from Paul_Cotton

<Zakim> dom, you wanted to comment on html media capture

dom: my understanding of tobie 's comments

<tobie> …and I'm lurking on irc

dom: the fact that the capture attribute takes values that takes this device or that
... is introducing unneeded duplication
... with the accept
... a simple capture boolean would be sufficient
... the type of file we want is already specified by accept
... to filter the kind of devices

fjh: why do we need the boolean at all?

Josh_Soref: from my perspective, we don't

dom: we've had that discussion many times
... to streamline the user interaction
... if you're building a camera app
... you don't want the user to have to go through a selection from a file dialog system
... you can have a better ui

Josh_Soref: people are asserting that UAs won't make useful UIs
... that the browser won't be able to offer a split-UI of browse+live capture
... but it certainly could do that

dom: if we have a capture bit, it could provide a more streamlined attribute

<dom> CoreMob Camera demo app

fjh: tobie was mentioning local manipulation
... assuming you have a very simple camera app
... you'd need to do server side processing
... we're conflating the UA could do clever things
... assuming it isn't doing that

Josh_Soref: about how form submission works

<fjh> i was assuming auto-submit for html media capture

Josh_Soref: no <input type=file> is ever automatically data in JS
... the page either has to trigger a submit to itself
... or have itself or the user trigger a genuine submit to a real server

fjh: thanks, that's clear enough

<Zakim> dom, you wanted to respond to Josh on filesystem-also-use-case

fjh: i wasn't thinking in those terms at all

dom: Josh_Soref, you mentioned that maybe the user wants to interact with files from media gallery
... in a Camera application
... assuming that the same UI would be the same
... is overconstraining the space
... for building good camera apps
... with this technology
... if we really want to enable good UX
... then I think we need to give this level of granularity to authors
... i don't see why we shouldn't

fjh: i think i'd like AnssiK to speak

<tobie> Not part of DAP, but can I join this call?

<dom> [Josh_Soref is revisiting the usefulness of this; I'm stating what I heard tobie say, that a boolean attribute would be sufficient]

dom: my perspective is what we're going to get from the call is not different in terms of IPR from the list
... so IPR constraints won't be different

AnssiK: my position is that we should learn from developers

<AnssiK> http://www.html5rocks.com/en/tutorials/getusermedia/intro/#comment-655251953

AnssiK: one comment on this approach
... in the comments section, you can find some discussion
... try to start with the UCs and running code

<dom> [I'm sympathetic to tobie's comment on a boolean being sufficient; the only reason I'm hesitant about it the fact that android is already shipping with keywords rather than boolean, but this could probably be dealt with]

AnssiK: i think CoreMob's Cam app running code

tobie: Hi, thanks for letting me join this call
... i was lurking, i thought since i was on the mailing list, i thought i should jump in
... a couple of corrections
... to talk about the implementation of media capture
... we built a number of prototypes
... it's completely possible to get all the data in javascript
... we're just using it to trigger the camera application
... we're not sticking it into an actual <form> for display

fjh: Josh_Soref was just saying that you have to script something to retrieve the data

tobie: i don't know how file inputs work for regular file content
... you can actually access the file object from js
... if not, you can submit it

fjh: did i see you offer to update the text?

tobie: i suggested it should be clearer
... AnssiK suggested i write something
... i could give it a go, but it depends on time frames
... it's on my todo list
... i can do it before the end of the year

Josh_Soref: that sounds good

fjh: that should probably work

tobie: i could bump it up

fjh: that'd be good, otherwise we might lose momentum

tobie: i'll move that up

fjh: so a couple of weeks?

tobie: sure

fjh: dom, does the make sense?

dom: sure
... but still question of boolean or keywords?

fjh: that's the next thing
... we thought we resolved that issue
... but it seems there's enough feedback
... to maybe change it
... AnssiK argued we could go either way
... it seems there's some consensus on the call to change it to a boolean

<AnssiK> http://www.w3.org/2009/dap/wiki/ImplementationStatus#HTML_Media_Capture

fjh: although dom had concenrs about existing Android implementations

<dom> [the question would be to know what implementors are ready to go with, I think]

AnssiK: we know there are partial implementations based on the specification as currently written
... Chrome for Android is the most complete
... I know BB10 browser passes Ringmark
... Josh_Soref are you in a position to comment on unreleased products?

Josh_Soref: of course i'm not in a position to comment on such things

AnssiK: it seems there are some implementations out there

<tobie> For ref, rng.io test: https://github.com/facebook/rng.io/blob/master/tests/html-media-capture/test.js

AnssiK: android 3/4 are hybrids

Josh_Soref: there's a BB10 simulator you can download that includes the browser

AnssiK: that seems to be all that the test could do automatic

Josh_Soref: you could do more testing

tobie: absolutely, you could do read-write cycle tests for more

[ AnssiK reads from html5rocks, noting that developers appear to like the spec as currently written. ]

AnssiK: i think we shouldn't just dump this and go to the boolean

Josh_Soref: the question is would the boolean be functionally equivalent to what they want

dom: i think that the boolean would work just as well for them
... there's of course the concern about the deployed implementations
... for expressiveness, the boolean approach is just as good

AnssiK: obviously this should be folded to HTML.next umbrella
... do we continue this in DAP or move it to HTML WG?

fjh: why would you raise that issue, why would we have to move it?

dom: my understanding of the current HTML WG plan
... other WGs than HTML WG can develop extensions to HTML markup as long as it's in scope to their charter
... if we wanted to, we could ask HTML WG to take this over
... if we want to keep working on this, we don't have to move it to the HTML WG

<fjh> josh_soref: how likely are existing implementations able to update if we change this

dom: i think there's a migration path
... i don't think anyone would really do capture=filesystem
... i think we could device a migration path, or people could do so

<Zakim> fjh, you wanted to talk about anssi change and to suggest approach

dom: i think the question is whether people are interested in migrating/willing to migrate

fjh: it sounds like there's a lot of arguments to make this change, on the list and on this call
... i'm not sure if it's the right thing to just edit the spec
... it sounds like if we could write down the proposed change and share it with people
... it might be easier to make progress
... i'm hesitant to just make the change
... doing a copy-paste from a draft proposal would be cleaner
... i think we need to reach out to people and see what they think of this
... i think we need a concrete proposal
... we need the proposed changes to the spec and the rationale
... and i'd expect people to take that and go to people and see if it's ok

Josh_Soref: does anyone know what IE10 does?

fjh: that was one of my questions

AnssiK: i remember AdrianBa posted
... to a mailing list
... he said something like we aren't prioritizing this

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012May/0242.html

fjh: ... they see little value of the capture attribute

Josh_Soref: it won't hurt them for this change to be made

AnssiK: what has historically happened, we've had one non-major browser

gmandyam: chrome only became default after 4
... of android

AnssiK: HTML5 spec sometimes considers actual implementation state
... this isn't such a situation

tobie: it's on stock android browser

Josh_Soref: but the behavior is different

AnssiK: yes, the behavior is different

<fjh> what I am hearing on the call is that the change to boolean is possible

AnssiK: it's an earlier iteration

Josh_Soref: i think so
... AnssiK, do you want to do it?

AnssiK: i'll need to do it

fjh: not as a spec edit

<dom> [I would personally prefer reusing "capture"]

Josh_Soref: i'm happy with just keeping the attribute name

<tobie> +1

fjh: let's keep the name

AnssiK: that will give us some backwards compat story

<fjh> ACTION: anssik to draft proposal outlining rationale and proposed spec changes to change capture attribute to booleans [recorded in http://www.w3.org/2012/11/28-dap-minutes.html#action01]

<trackbot> Sorry, couldn't find anssik. You can review and register nicknames at <http://www.w3.org/2009/dap/track/users>.

AnssiK: this will be the smallest spec ever

<fjh> ACTION: anssi to draft proposal outlining rationale and proposed spec changes to change capture attribute to booleans [recorded in http://www.w3.org/2012/11/28-dap-minutes.html#action02]

<trackbot> Created ACTION-595 - Draft proposal outlining rationale and proposed spec changes to change capture attribute to booleans [on Anssi Kostiainen - due 2012-12-05].

fjh: the idea is a proposal without making changes to the spec
... i want to slow it down
... get consensus and agreement before we edit the spec
... you'll copy-paste from the proposal into the spec once we have agreement
... the goal is to have consensus
... speaking of editing the spec
... i don't think i agreed with your last edit to the spec
... you changed camera to say camera is camera
... i'd suggest reverting it

AnssiK: that'll be a moot point

Josh_Soref: i'd recommend you revert it

fjh: we had an agreement as a group to make that change

AnssiK: ok, i'll do the revert and then start the discussion about the boolean

tobie: i think like AnssiK it's a moot point if we go for boolean

Josh_Soref: i don't want people to yell at us about that

<fjh> we need to keep what we had as consensus reflected in the document, despite proposals on the table

Josh_Soref: while we're trying to get consensus on boolean

fjh: i'm trying to make sure people are heard and follow process as much as possible
... otherwise, later on, we'll have people complaining later on in the process
... it's my job to be a process warrior

AnssiK: you're doing a great job

fjh: i'll need to deal w/ LC feedback
... i tried to go through and close everything out
... i'm trying to manage Disposition offline

Discovery API

<fjh> Distinguishing same service offered by multiple devices, http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0074.html

fjh: i don't know... Cathy, have you looked into this?

Cathy: i'm going to send a response

<tobie> [Thanks for your time, all.]

Battery Testing Update

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0068.html

<fjh> Thanks for joining Tobie

AnssiK: thanks dom for the feedback
... i wasn't aware of idlharness.js
... it looks like it could be very useful
... i'm not sure how complete it is
... i haven't looked at the source completely

dom: i'm fairly sure it isn't complete
... i think your manual tests were more thorough than what idlharness is doing
... i'd prefer us to fix idlharness
... rather than doing our own

AnssiK: is this JamesG or Ms2ger?

dom: i can't remember

AnssiK: i think they were both involved
... i've added your tests to hg
... so if you run both tests, you should get fairly good coverage
... the libraries are now relative urls
... so you can run your own local version
... i added the meta tags
... which tool uses the meta info?

<dom> http://w3c-test.org/framework/app/

dom: it's w3c test framework
... i'm not entirely sure how much it uses it
... by documenting which tests needs a human, you can allow the other tests to be run automatically much easier

<AnssiK> http://nightly.mozilla.org/

AnssiK: you should use Firefox Nightly to run these tests
... i got feedback that long running tests have no feedback, so i added a countdown timer
... and i tried to split the prime function into chunks
... it surprised me that it brought down my browser

<dom> (I guess that would be a useful test for workers :)

Josh_Soref: it might be GC or...

<fjh> josh_soref: might be garbage collection or the CPU limitations

AnssiK: i'm not sure if Workers have any QoI tests

<dom> (quality of impl is traditionally out of scope for W3C specs)

<dom> (and W3C tests as a result)

fjh: AnssiK, how complete are we/far from done?

AnssiK: should we fix idlharness and move to use that one?
... do we go to the manual tests
... patching idlharness might take a while

dom: it isn't a requirement, it's a matter of being a good guy

AnssiK: if we don't use idlharness, i think we're fairly close to being complete
... obviously you can't test everything, but i test the edge cases that can be tested
... empty battery is fairly hard to test

fjh: you mentioned trying to run the battery down

<dom> (I found indeed the test suite to be quite complete in terms of coverage, but I haven't done a formal analysis yet)

fjh: but no one offered you hardware

AnssiK: the device may completely shutdown before you complete the test suite
... i got rid of the alert which wasn't very accessible

Josh_Soref: what do you mean by accessible

AnssiK: having alert required you to have to manually dismiss

fjh: i think he means that you had to be present - interacting
... before it ran to completion
... fixing idlharness - such things tend to get bigger
... to get beyond CR
... with test cases, we just need two implementations
... where are we with that?

<AnssiK> http://www.w3.org/2009/dap/wiki/ImplementationStatus#Battery_Status_API

<dom> (we discussed this at the F2F http://www.w3.org/2012/11/01-dap-minutes.html#item05 )

AnssiK: let me see if the implementation status wiki is up to date

<dom> "dom: until we get another browser implementation the question is pretty moot"

Josh_Soref: we're waiting for a serious browser

<fjh> serious means deployed browser, not test implementation

AnssiK: so we need two implementations and tests and then we can go forward
... so we're short an implementation

fjh: we need no features at risk
... i'm assuming we don't have any issues
... but we need another implementation
... we'll need something in a documented form

AnssiK: let's take this offline so i understand the process hoops we need to jump forward

Proximity / Sensors

fjh: there's discussion about extending scope of proximity beyond the initial scope
... but that requires niklas to get back to us

<AnssiK> http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0053.html

<AnssiK> http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0035.html

AnssiK: that's my proposal -- to push it to v2

<fjh> fjh: 1. one list suggestion has been to extend proximity beyond the use case we have been working on.

Josh_Soref: i'm +1 to that

<fjh> I'd argue that we not extend the scope

AnssiK: i prepared v1 for publishing

<fjh> fjh: 2. this is part of overall concern for providing for use cases with sensors - any discussion of that will require first looking at the use cases. Niklas has action item for that.

<fjh> that said, we may decide certain items are out of scope or require new specs

fjh: i thought we decided to do proximity and ambient LC at the same time

AnssiK: yes
... my point is we have v1 now, we have implementations and UCs

<fjh> From process perspective implementations are not required for LC

AnssiK: we can always do v2, v3, once we have implementations and hardware
... it isn't end of world if we don't get it in v1

fjh: i agree
... car stuff is pretty vague
... i think it's a v2 thing

AnssiK: when i announced LC snapshot

<fjh> my opinion, not chair decision

AnssiK: if people had concerns, i asked them to resolve them by today, because tomorrow is pubdate
... nwidell raised something, but promised to do a mail

fjh: i'm not sure we can do it in one day

AnssiK: let me know if you need me to update the document

fjh: i think we should plan for Tuesday publication

dom: for LC, there's no approval needed, it's a WG decision
... it's usually preferred if the WG chairs are warned in advance
... if we have WGs from which we want review

fjh: i'm not sure who we'd ask for review?

dom: maybe sysapps, privacy, webapps?

fjh: what do we share with them?

Josh_Soref: don't we publish LC and then ask them to review it during LC

dom: we don't need to send them the draft
... we just tell them we're going to have LC
... and that we'll be asking for their review

<AnssiK> note publishing deadlines for EoY: http://www.w3.org/mid/50AA2591.3070006@nokia.com

fjh: we never picked a LC period, did we?
... we don't have to follow ArtB's dates
... the only one that matters is the last-day-to-publish which is a w3 thing
... if we can pick a LC period here
... why don't we make a resolution that we'll publish a LC of proximity on next thursday
... on December 6
... one month isn't enough
... i'd say we have a LC period ending Jan 24
... it's 7 weeks
... i don't think there's an urgency requiring it to be shorter
... dom what do you think?

dom: do we have implementations?

AnssiK: we do

<fjh> proposed RESOLUTION: publish Last Call WD of Proximity API on 6 December 2012 with Last Call ending 24 January 2012

<AnssiK> http://www.w3.org/2009/dap/wiki/ImplementationStatus#Proximity_Events

RESOLUTION: publish Last Call WD of Proximity API on 6 December 2012 with Last Call ending 24 January 2012

<fjh> ACTION: anssi to update publication draft to have publication date of 6 December 2012 and LC end date of 24 January 2013 [recorded in http://www.w3.org/2012/11/28-dap-minutes.html#action03]

<trackbot> Created ACTION-596 - Update publication draft to have publication date of 6 December 2012 and LC end date of 24 January 2013 [on Anssi Kostiainen - due 2012-12-05].

<fjh> ACTION: fjh to announce plans for LC publication to webapps, sys apps, ping [recorded in http://www.w3.org/2012/11/28-dap-minutes.html#action04]

<trackbot> Created ACTION-597 - Announce plans for LC publication to webapps, sys apps, ping [on Frederick Hirsch - due 2012-12-05].

F2F planning

<fjh> Questionnaire for time frame (March/April) of next F2F, https://www.w3.org/2002/09/wbs/43696/f2fQ12013/

fjh: if you haven't done so, please fill out the questionaire

dom: fjh, the questionnaire is closing today
... should i extend it?

fjh: i think we should extend it
... to December, 20, 15, or 12?
... let's extend it to December 14

dom: what's our target?
... are we expecting answers from specific people or specific numbers of people?

fjh: let's talk about what we'll talk about at the F2F?
... resolve Web Intents/Web Activities
... so we'd want Greg
... and jhawkins
... and move to REC for next F2F
... get somewhere with Discovery
... so richt, Claus
... Cathy
... another go with sensors
... although that's low priority
... interop - advancing specs
... Contacts/Calendar
... figure out how we'll do that
... the usual suspects need to be there
... and key people from Task Force

dom: I extended it to Dec 11
... but I think you should get in touch with those people directly

fjh: yes, i agree
... my experience is that we've always ended up extending questionnaires

<fjh> ACTION: fjh to follow up on F2F interest with relevant participants [recorded in http://www.w3.org/2012/11/28-dap-minutes.html#action05]

<trackbot> Created ACTION-598 - Follow up on F2F interest with relevant participants [on Frederick Hirsch - due 2012-12-05].

fjh: i'll follow up offline

<fjh> ACTION: fjh to set up agenda page for F2F to solicit feedback and ideas [recorded in http://www.w3.org/2012/11/28-dap-minutes.html#action06]

<trackbot> Created ACTION-599 - Set up agenda page for F2F to solicit feedback and ideas [on Frederick Hirsch - due 2012-12-05].

fjh: plan is to get an idea for dates in December
... and get a host early January
... that won't give us much time to make travel arrangements

Action Review

fjh: we'll do that offline

AOB

<fjh> http://www.w3.org/2009/dap/track/actions/open

s/Topic: AOB//

fjh: AnssiK, you'll work on the proposal
... for Media Capture
... and work on Proximity for Publication
... and i'll work on YYY
... Cathy will respond about service discovery
... i think we're done
... thanks very much
... thanks a whole lot

<fjh> s/YYY/preparing process wise for Proximity LC publication/

trackbot, end meeting

- DRAFT -

Device APIs Working Group Teleconference

28 Nov 2012

Attendees

Contents