- 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