Device APIs Working Group Teleconference -- 05 Oct 2011

<trackbot> Date: 05 October 2011

<fjh> Agenda: /topic http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0001.html

<fjh> s;Agenda: /topic http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0001.html;;

<scribe> Scribe: Josh_Soref

<Clarke> How do we know which number is us?

Administrative

<fjh> TPAC registration reminder, deadline 10 Oct hotel, 14 Oct registration, http://www.w3.org/wiki/TPAC2011

<fjh> http://lists.w3.org/Archives/Member/member-device-apis/2011Sep/0003.html

fjh: TPAC registration deadline (fee increase) is coming shortly

<fjh> questionnaire for noting remote attendance fixed, http://lists.w3.org/Archives/Member/member-device-apis/2011Oct/0000.html

Clarke: this is my first TPAC...
... Should i attend the TPAC Plenary?

fjh: there is an Unconference bit at the Plenary which has session related to DAP architectural approach, JS API and HTTP-based APIs

darobin: in general attending the Plenary is useful
... even if only for the social benefits

Minutes approval

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/att-0134/minutes-2011-09-28.html

RESOLUTION Minutes from 28 Sep are approved

Battery

fjh: there was a discussion of Battery on the TF mailing list
... dom sent a message about it

[ Note that the TF Mailing list is not currently archiving correctly ]

AnssiK: please join the mailing list

<dom> [ indeed, Josh_Soref; I've asked for this to be fixed but haven't heard back yet]

AnssiK: otherwise we'd be forking the discussion
... so we need to direct all discussion of Battery to that list

fjh: please sign up if you're interested so you don't miss that discussion

darobin: if you need help signing up, please contact me

Sensors

<fjh> Draft, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0136.html (Jose)

<fjh> comment, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0138.html

fjh: I know Jose and dom sent emails

Dzung_Tran: There's work to be done esp. with Timestamp and Accuracy
... I'll check something in this week

<dom> welcome jose to DAP, jose

jcantera: We're also thinking on the discovery of sensors available
... using this approach you could cover discovery
... [ under sensors ? ]

Claes: I'm glad that Discovery is continuing
... have you discovered the scope of where sensors can exist?
... sensors can be internal to the device
... or connected
... or in the local network
... or they can be in the cloud

jcantera: the idea is to have a method
... for example listSensors
... and you can provide a type of sensor
... which would return a reference to a sensor of that type
... if the listSensors implementation can detect a sensor in the environment
... then you could get access to a device that isn't within the device per se
... this approach covers the Discovery use case
... the other approach would be to have some binding between Sensors
... and Discovery.
... That path could delay Sensors.

Claes: I can understand making Sensors not depend on another specification
... I sent a mail to the mailing list
... where I provide information about the Webinos API and Discover

jcantera: Leaving things separated between Sensors and Discovery
... where Discovery returns something which could then be used by Sensors
... [ is possible ]
... I'll send an updated proposal

Claes: another issue was needing to expose a method for
... details about the discovered sensor
... there are use cases where a web application wants to be tailored to a specific sensor
... this sort of information is exposed by Android

jcantera: Yes, I understand there are interesting attributes available from the platform
... we could for example have something in the api for sensor metadata

<Claes> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0004.html

dom: To reiterate my suggestion

<darobin> +1

dom: we should remove the part of the Sensor api that overlaps with the DeviceOrientation spec

<AnssiK> +1 to remove overlapping parts

jcantera: Should we have the Sensor API agnostic to the data types it provides?
... or just have it drop the conflicting bits?

dom: my suggestion is simply dropping the overlap
... if we see value in generic data types, we can do that
... but for now, we should start with more concrete items and avoid the overlap

darobin: we also see some value in more lower level bits than provided by the Orientation spec
... for that, it would be valuable to discuss that with the GeoLocation WG
... which manages that spec

jcantera: I agree with dom, that we should avoid confusion/conflict with other groups/specs
... from a technical perspective, DeviceMotion is not targeted to get Raw Sensor Data
... it's designed to get general motion
... which involves removing Noise and other stuff

<dom> (I'm fairly sure that at least Firefox sends raw data for devicemotion)

<fjh> +1 avoid overlap

<darobin> [it's worth finding out]

jcantera: You also can't control the precision, resolution, or time intervals

<dom> [this sounds like good feedback to send to the Geo WG :) ]

jcantera: Could we contact the Editors of that spec about this?

dom: I'd suggest you send feedback to their mailing list
... I'm not sure they've fully considered them
... I agree these considerations need to be discussed

darobin: it's especially important to give them use cases for providing Raw information

jcantera: One of the use cases is Games
... in Games, you need to have a good rate of delivery of sensor data
... otherwise the game will not be "responsive"

Clarke: My question is about Scope
... there seems to be a specific type of Sensor, covered here
... things relating to Context...
... things you'd find in a mobile phone
... in other groups I'm in, we're looking at more a broad scope
... things like Burglar alarms, Fire alarms, Temperature, ...
... If we aren't looking at that, we should make a note that they're things which we could look at in the future

<Claes> +1 for Clarke's comment

jcantera: We have left the API open to deal with new data types
... the spec has defined a vocabulary of sensors
... but it isn't closed to new sensors
... Concerning discovery,
... let's have an API that can work seemlessly with Discovery
... Or have a simple mechanism to support simple Discovery
... give me whatever Sensors are in the Environment and then I will query them

+1 to darobin's proposal to not have useless prefixes/things that look like schemes

Clarke: I agree with focusing on a subset of usecases
... if we're going to have a Sensor api that's general enough to cover sensors that are included in other specifications
... Do we want to include Actuators?

jcantera: Actuators being things where we can set values?

<fjh> are we having scope creep here?

Clarke: Right, setting values on a Thermostat, or Ringing a bell

jcantera: That wasn't initially in the scope

Clarke: I just want to be clear on the scope

<Dzung_Tran> I think we should do that later

<dom> +1 to start with a limited scope (local sensors)

<darobin> +1 indeed

<Zakim> Josh_Soref, you wanted to object

<darobin> [I think that if we have a decent model to expose sensor data for local sensors, it should be easily adapted to expose remote sensors]

<fjh> josh_soref: want interop between various sensors and applications as consumer

<fjh> josh_soref: concern about vendor name and model details

Clarke: Let's say that I want to customize my application to details from a specific sensor

<Zakim> Josh_Soref, you wanted to respond

<darobin> Josh_Soref: a long time ago a browser was called Mozilla, people started UA sniffing for it, and now all browsers are identified as Mozilla

<fjh> josh_soref: concern about analogy web browser sniffing for features, only work with specific browser etc

<darobin> Josh_Soref: providing brand, etc. information is not beneficial to anyone

<AnssiK> contrast this against feature detection (good) vs. navigator.userAgent sniffing (bad)

Clarke: if you expose the data/attributes in a standardized way
... and you also have a textual name of your company
... is that ok?
... or should you be forbidden to expose the name of your company?

<Dzung_Tran> I don't see a use for it

<fjh> so what you are saying is that if you don't convey company/product identity information then requiring a specific company/product for feature can be prevented

<fjh> clarke: this eliminates some branding

<fjh> josh_soref: branding at this level doesn't matter

Josh_Soref: it's true that vendor information exists at lower levels, but those should only really be relevant at most at the Device Driver layer

Clarke: I have one use case which is legitimate for branding
... Say I have 3 printers available
... As a user, having those names available is useful to me

darobin: I agree there's a use case for that
... I suspect that we'll be more successful
... if we let people add the brand info they want to, and recommend that developers rely on feature detection for most cases, which is a known best practice
... Recommend that services not rely on brand names

Clarke: I hope that textual information isn't a big concern

[ note that UserAgents are Textual Information, as was the iPod-iTunes vendor ID , and they were both heavily abused ]

Claes: I'd like to ensure that there are at least locally connected devices

<fjh> have a SHOULD NOT use brand info for feature detection??

Claes: I agree that we shouldn't duplicate other existing devices

<Zakim> darobin, you wanted to ask where the "sensor:" prefix comes from and if we can just kill it

Claes: For demo purposes, DeviceOrientation is a good demo
... even though it shouldn't necessarily something that should be included in the end

darobin: concerning the sensor api
... I was wondering where the 'sensor:' prefix comes from
... and if it's really useful

<dom> +1 ; the SensorConnection() constructor already serves as namespacing for events

darobin: i think 'temperature' is better than 'sensor:temperature'

jcantera: the intention initially was to have a URI for sensors

darobin: do you think that's actually useful?

jcantera: if you could do <sensor:themometer/specific-instance>

<dom> -1 on URI for specific sensors

jcantera: you could have specific refrences that you could individually reference

darobin: wouldn't it be simpler to just pass parameters to a constructor?

<darobin> new SensorConnection("temperature", { name: foo }) vs new SensorConnection("sensor:temperature/" + foo);

jcantera: you prefer not to have a URI?

darobin: yes

jcantera: ok, I agree, that can be dropped

darobin: it's a bit dodgy to have a URI you can't use in the URL bar
... or link to
... etc.

<Zakim> Josh_Soref, you wanted to note that the UA can let the user see this without exposing it to web apps

<darobin> +1 for start simple — add complexity when use cases come in

dom: the question of how do you keep track of single sensors vs. multiple sensors
... requires more thinking
... and should be addressed later

darobin: should we have an issue about Single v. Multiple sensors?

<darobin> ISSUE: How to handle exposing single vs multiple sensors of the same type

<trackbot> Created ISSUE-120 - How to handle exposing single vs multiple sensors of the same type ; please complete additional details at http://www.w3.org/2009/dap/track/issues/120/edit .

<Zakim> darobin, you wanted to say blah blah

<fjh> josh_soref: about use case of picking printer, this is essential for multiple sensor use case

<fjh> ... once user picks sensor then app doesn't need branding info

<dom> +1 for UA to be a broker for selecting sensors (but that needs refinement)

<fjh> ... suggests ua exposes information selectively depending on whether discovery or not

darobin: proposals to the mailing list would be appreciated
... someone could take an action item

<darobin> ACTION: Josh to write to the list to explain UA mediation in selecting sensors [recorded in http://www.w3.org/2011/10/05-dap-minutes.html#action01]

<trackbot> Created ACTION-456 - Write to the list to explain UA mediation in selecting sensors [on Josh Soref - due 2011-10-12].

Discovery

fjh: well, this was touched on in Sensors discussion ...

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0141.html

<AnssiK> btw. thanks Claes for updating http://www.w3.org/2009/dap/wiki/ServiceDiscoveryComparison

<fjh> +1 thanks to Claes for the comparison wiki page

Claes: there will be a post to the list on Use Cases

Clarke: i think the next step is to try to consolidate them
... our goal is to determine which use cases can't be covered with current specs
... If we could work the Webinos use cases into that, that would be great

Claes: We're working on that
... and hopefully we can talk more about that next week

darobin: any volunteers to start editing a document?

Clarke: we've already created a document

link?

<Claes> http://www.w3.org/2009/dap/wiki/ServiceDiscoveryUseCases

<dom> http://www.w3.org/2009/dap/wiki/ServiceDiscoveryUseCases

Clarke: if you want to edit that wiki, please contribute, especially for consolidation

darobin: that's a good first step
... the next step would be to try to draft something into a spec
... but is this too early?

Clarke: the spec that Opera and Cable Labs are submitting
... is based on the w3 requirements listed here

[ time check - we're past the 1 hour mark -- which is well over our recent average ]

darobin: if people from Webinos are comfortable, i'd like to encourage a draft be put into cvs/Hg
... objections?

Claes: i'd rather we wait a week, i think we need to have a bit more discussion

darobin: anything else on our agenda for Discovery?

[ no ]

TPAC Agenda

<darobin> http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_%28TPAC%29

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0010.html

fjh: he suggested next steps for HTML Media Capture, WebRTC and TAG
... for Joint Meetings
... I'm not sure what to do with HTML Media Capture

darobin: I don't know that a joint meeting with the HTML WG would be useful

fjh: WebRTC would be useful

darobin: TAG will be a discussion about HTTP based APIs

fjh: it's really one or two people joining us

darobin: don't hesitate to edit the Wiki
... add topics to the Top

<fjh> TAG is having architectural item on its agenda this week

darobin: if you have preferences for times (because of conflicts or you're calling in), certainly tell us
... we'll try to work that in
... questions on the TPAC agenda?

AOB

<darobin> RRSAgent: stop

- DRAFT -

Device APIs Working Group Teleconference

05 Oct 2011

Attendees

Contents