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

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

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

Battery Testing Update

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?

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?

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

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

Action Review

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