See also: IRC log
<trackbot> Date: 12 October 2011
<scribe> Scribe: Josh_Soref
<fjh> Device Status Task Force mailing list at http://lists.w3.org/Archives/Public/public-device-status/2011Oct/0000.html
<fjh> Last Call WebIDL 18 October deadline, http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0040.html
<fjh> Workshop: The Future of Offline Web Applications, deadline 12 Oct, http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0005.html
<fjh> TPAC reminder, hotel, http://lists.w3.org/Archives/Member/member-device-apis/2011Oct/0001.html
<fjh> Questionnaire for noting remote attendance open to 22 October but please respond now if you plan to dial in, http://www.w3.org/2002/09/wbs/43696/tpac2011/
<darobin> SEND IN YOUR POSITION PAPERS: http://www.w3.org/2011/web-apps-ws/
<Deepanshu> I'm the one dialing form China, so yes anything likr +86 is me Depanshu
RESOLUTION: Next week's call is canceled
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/att-0013/minutes-2011-10-05.html
RESOLUTION: Minutes from October 5th are approved
<fjh> http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_(TPAC)#Day_1.2C_Thursday_3_November_2011_.289am_-_5pm.29
[ fjh reads the Agenda ]
jsalsman: I have a question about process at the F2F
fjh: The process at W3 means "consensus is no formal objection", we don't recuse people, and work is done in public as much as possible..
<darobin> +1 we don't recuse people, we only use as much process as we need
fjh: Everyone can bring something to the table.
[ fjh tries to move on with the Agenda ]
<jsalsman> yes
[ fjh resumes reading the Agenda ]
AnssiK: The Web Events group is meeting on Tuesday.
... I haven't gotten a reply from them regarding vibration.
... I won't be available on Monday
... but I will be available for the rest of the week
Josh_Soref: I'll be around for the whole week, but I have a number of groups I need to drop in on for Monday/Tuesday
<fjh> Updated draft, http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0025.html (Jose)
<fjh> Comments from Bryan, http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0026.html
<fjh> Comments from Claes, http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0041.html
Dzung_Tran: The comments are good
... including comments on Discovery and Network type devices
... the initial scope of this was "in device sensors only"
... connected or integrated.
... That was the original scope of the spec,
... I'd like to leave it like that.
... I'd like to keep the spec simple enough that it can be implemented
[ Cross chatter ]
Dzung_Tran: There was an item about Privacy,
... I would like to talk about it at the F2F
<jsalsman> +1 discuss privacy on email list instead of face to face
Dzung_Tran: one thing we could do is use the Permission API
... before Discovery.
... There are some edits that I will do this week to answer questions posed on the list
Claes: With the mail I sent on the Sensors api,
... there are two main concerns:
... The first is the scope of the api
... I'm not sure that we should limit the scope of the api to just internal device sensors --
... I'm not sure if we should build Discovery into the Sensor api
... or whether it should rely on an external api for Discovery.
... If we just look at use cases we want to solve,
... it would be too severe of a limitation to only handle internal sensors.
... I think the API must somehow at least handle external but locally connected sensors.
<fjh> +1 to discussing sensor privacy at f2f (as well as on email list)
Dzung_Tran: I think the API today will handle Locally connected sensors.
... We could depend on a general Discovery API
... but it would depend on a timeline for such an API
Claes: I'm not sure, but I think it's a major detail
... The other issue is how Discovery should work
... whether we should have a callback for
<Zakim> fjh, you wanted to ask dzung re privacy email
fjh: Will you start an email thread on privacy?
Dzung_Tran: I will respond to privacy in the email thread
bryan: I sent an email
... I think we can use two approaches:
... - if the user agent has visibility to external sensors due to device capability to discover them, it can expose them through the API
... - we need to consider a general purpose in-network service discovery capability for which sensor API can be one of the services, like other APIs
<Zakim> AnssiK, you wanted to note that we should make most, or all of the interface async if we want to support remote sensors
AnssiK: wanted to note that we should make most, or all of the interface async if we want to support remote sensors
darobin: It's likely that even local sensors can be slow
AnssiK: That's a fair consideration
... maybe we should design with that consideration in mind
<jsalsman> There is related javascript API discovery proposal at http://www.w3.org/2011/09/webtv/papers/W3C_HNTF_Position_Paper_Sept_2011.pdf
darobin: Does someone want to take an ACTION item about Remote/Local in Discovery?
Claes: I can take that action
<darobin> ACTION: Claes to create an ISSUE describing the local vs remote, integration of discovery into sensors, etc. problems [recorded in http://www.w3.org/2011/10/12-dap-minutes.html#action01]
<trackbot> Created ACTION-457 - Create an ISSUE describing the local vs remote, integration of discovery into sensors, etc. problems [on Claes Nilsson - due 2011-10-19].
<fjh> Javascript-only implementation requirement, http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0034.html
fjh: Bryan, you sent something to the list about a new requirement
bryan: There's nothing in the api that would prevent it from being implemented purely as JS
... if we had a way for devices to advertize themselves
<jsalsman> -1 on trying to reach more devices by not exposing information
<darobin> +1 to full JS implementations in general
Clarke: We have an implementation that uses a Java Applet in combination with JavaScript
... that doesn't impact the browser
... I think the goal is to have something that doesn't impact the browser
bryan: I agree
... using a local helper
... something that's callable through JS
... is an option
... As the spec develops, I'll be trying to prototype it without UA support
AnssiK: I think having two alternative designs which are functionally equivalent
... but where one can be implemented in Pure JS
... I think favoring the latter is a good approach.
fjh: I suggest we need to record this objective, in the document or elsewhere
AnssiK: During the Battery spec design, we got feedback
... and adjusted to enable a Pure JS / Shim JS approach.
... Maybe we should add this to the API Checklist page
<darobin> +1
<fjh> +1 to adding to API checklist wiki page
AnssiK: I'll edit the wiki page
<Claes> First issue with the current sensor API proposal is the scope of the API, in-device sensors only, 2: 1 plus locally connected sensors, 3: 2 plus networked sensors. Second issue is how sensor discovery method is specified: Callback per found sensor or callback when user has selected sensor (better from privacy aspects).
Clarke: There are some issues that I don't think you can do in current browsers.
... There are Cross Origin restrictions with XHR
... which the Java applet can work around
... but this is a stub
... in the future it wouldn't be needed
fjh: AnssiK you had some suggestions
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0037.html
fjh: I think we'll talk about this more at the F2F
AnssiK: I may have nothing to add to that
... there's a very early implementation from the Mozilla folks in Gecko
... it's very recent work, let me track it
<Zakim> darobin, you wanted to talk about putting it in the TF
AnssiK: If they have made progress, by TPAC, maybe we can
darobin: It would be great if you could pick it up
<fjh> +1 thanks to anssi for volunteering here
darobin: Since this comes from Mozilla, should it be in the TF?
AnssiK: I think if they're more comfortable with the TF
... then we can use the TF list
<darobin> +1 to simple and modest
AnssiK: I'd like to do a simple thing
... the game controller has a few use cases
... we need to be very careful when it comes to scoping
... let's create very well scoped use cases
... and then spec it out
darobin: I think the hardest part of the specification is how it interacts with page-visibility
AnssiK: I think the mozilla folks have a proposal
... if the page is in the background, no vibration effects are acted upon
fjh: darobin, we need to figure out what we're going to do with this
<jsalsman> wonsuk: what are you thinking of for the list of 'featureID's?
[ fjh will introduce this ]
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0027.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0030.html
fjh: jsalsman, there are 3 different things in your email.
... Some of which were discussed, and some of which were technical
... Of that list of items, (1) some were addressed
... (2) the second was about net neutrality per-se
... (3) the third was about codecs.
... With the check list, I thought we had gone through that (1).
... The second was net neutrality.
... The third was codecs, where I thought we wanted to remain neutral.
... jsalsman: Does that properly delimit your concerns?
jsalsman: Consider the case where there are no open standards
... implementers may end up using MP3
... The major consumers of audio is YouTube
... where they use FLAC on the desktop
... and Speex on mobile
fjh: I don't think it's necessarily appropriate for us to regulate some of this
... as it applies to other groups
darobin: When we discussed this in Korea?
... we decided to follow whatever WebRTC decides
jsalsman: the next bit is the US FCC's orders
fjh: I think Net Neutrality is a rather broad thing
darobin: We don't do Policy
jsalsman: Wasn't this The Device API and Policy
fjh: No, Policy was removed
... with the recharter
<jsalsman> when?
[ this summer ]
fjh: So you're saying that there's certain information that should be exposed
... and there may be something which is lacking in the current apis
jsalsman: Yes
... The process of publication involves making decisions about what is important and what is not.
... [An API enabling one to] Make a decision about how much bandwidth is available.
... [An API to detect] Whether there is a loss of data as the input is being transfered.
fjh: I'm trying to understand what to focus on.
... Which things are outside are scope.
... What we've already considered
jsalsman: Let's say I proposed a new bit was made available to the Network api:
... Saying that the API expose whether the device [vendor] has endorsed the FCC rule.
... How would that be received?
fjh: The other approach we have is that for our specs, we try to do things very simply in V.1
... and we tend to push things to V.2 for more complicated bits
... [ I'm not sure what's been recorded, please feel free to help the scribe by recording other bits. ]
... The topic of codecs is important but not necessarily the purview of this WG, as it relates to other standards etc.
<darobin> [not to mention US-only]
Clarke: I would NOT like to see an item in Yes/No form WRT the FCC's statement.
... I don't think the Cable industry would support anything like that
<jsalsman> Which of my proposals is the most important to exclude?
Clarke: I don't think that it's an issue appropriate to the Device API WG which doesn't deal with policy anyway
fjh: Without clarity about which attributes are of concern, I don't think we can address them
<Clarke> I would NOT like to see a yes/no item on a matter of political complex policy
<Zakim> bryan, you wanted to ask James to indicate what support the host devices already have for native applications to determine the characteristics that he is interested in further
bryan: If we could have further information about things to consider.
<jsalsman> I asked whether a representative of a device manufacturer would be able to report an accurate assessment of their own opinion on whether the manufacturer should inform customers, for example, of whether the manufacturer had endorsed the FCC's Network Neutrality Orders
bryan: Typically we focus on things which are already available on devices
... exposed to native applications
<fjh> I doubt you will get an answer to such a question from a technical wg participant
bryan: Our focus is on exposing those apis to web applications
... not about whether something is a good idea
... but on whether it is implementable
fjh: I think that's a good summary
<Clarke> Just the one statement. Reducing complex political policy to a simple yes/no indicator is absurd and out of scope for a technical working group
fjh: jsalsman: I think it isn't appropriate to expect policy answers from a technical WG
<jsalsman> another example would be whether the representative of an ISP would be able to accurately report their own opinion of whether devices report what their bandwidth, cost per bit, or whether the ISP is reputable. Would a secret ballot poll overcome these issues?
fjh: jsalsman: I'm asking you to take into account the current charter -- http://www.w3.org/2011/07/DeviceAPICharter.html
[ Adjourned ]