- From: Tran, Dzung D <dzung.d.tran@intel.com>
- Date: Thu, 17 Dec 2009 10:18:27 -0800
- To: Ian Hickson <ian@hixie.ch>
- CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
On Wed, 16 Dec 2009, Hickson, Ian wrote: > > On Wed, 16 Dec 2009, Tran, Dzung D wrote: >> >> How do you envision your work integrate with Device API WG's current >> >> spec? Is there some hand off between your <device> selector and >> >> Device API? Or not? >> > >> > Which spec did you have in mind? >> >> I was thinking of the current work with the Capture APIs as: >> http://dev.w3.org/2009/dap/camera/ > > Oh I assumed that this API was for the widget case -- in HTML4, you can > already do static image capture and non-streaming video or audio capture, > using <image type=file accept=...>. It's not widely supported yet, but > HTML5 elaborated a little on the idea and from talking with browser > vendors I wouldn't be surprised to see it implemented in the near future. I don't the intent of the WG is only provide APIs for widget case. If you think that the browser vendors will support the <image type=file accept=...> and the work you are doing with <device> happen in the near future then maybe there is no need for Capture API. >> I think in one of the example from Andrei Popescu you could handle the >> non-streaming capture as: >> >> <device type="mediaFile" onchange="update(this.data)"> >> >> function update(file) { // file is an object that implements interface File >> } > > This seems redundant with existing features. I'd be very reluctant to > introduce multiple ways to do things. Agree ------------ On another note, In the Device API WG, we were looking at sensors as in such things as: Proximity, NFC, Pressure, Ambient Light, Hall sensors...etc. This seems to fit into your <device> tag. Thoughts? Thanks Dzung Tran
Received on Thursday, 17 December 2009 18:19:04 UTC