See also: IRC log
<trackbot> Date: 28 November 2012
<gmandyam> Giri Mandyam from QuIC on the call
<scribe> scribe: Josh_Soref
<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
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.
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
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> user feedback on getusermedia tutorial at html5rocks
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> Implementation Status: 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
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
... 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#action01]
<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
<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.]
<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> nightly.mozilla.org - where you can download Mozilla Firefox nightly builds
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...
... 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> Implementation Status: 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
fjh: there's discussion about extending scope of proximity beyond the initial scope
... but that requires niklas to get back to us
<AnssiK> Proposal for addition field
<AnssiK> LC snapshot created
AnssiK: that's my proposal -- to push it to v2
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: 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.
... that said, we may decide certain items are out of scope or require new specs
... 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> Implementation Status: 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#action02]
<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#action03]
<trackbot> Created ACTION-597 - Announce plans for LC publication to webapps, sys apps, ping [on Frederick Hirsch - due 2012-12-05].
<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#action04]
<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#action05]
<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
fjh: we'll do that offline
<fjh> http://www.w3.org/2009/dap/track/actions/open
fjh: AnssiK, you'll work on the proposal
... for Media Capture
... and work on Proximity for Publication
... and i'll work on preparing process wise for Proximity LC publication
... Cathy will respond about service discovery
... i think we're done
... thanks very much
... thanks a whole lot
trackbot, end meeting