RE: <input type=photo> etc as Capture API

Definitely we don't want to invent a new URI scheme. I think there is some merit to the model in robin's previous post at: http://www.w3.org/mid/AB072C1D-8194-45A8-968E-5E44D3B8F96E@robineko.com

---
Dzung Tran
Intel Corp

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon
Sent: Friday, December 04, 2009 03:59 AM
To: Arve Bersvendsen
Cc: Ilkka Oksanen; public-device-apis@w3.org
Subject: Re: <input type=photo> etc as Capture API

On Dec 4, 2009, at 12:33 , Arve Bersvendsen wrote:
> On Fri, 04 Dec 2009 12:26:09 +0100, Robin Berjon <robin@robineko.com> wrote:
>> The code is simple enough, and typical enough, but my concern is whether this approach can scale to controlling the video. So in the above I've embedded the captured video in the page, but this assumes that it's already been recorded. How do I grow that into something that could stream it (streaming is hard enough already, I'm not sure how it marries to the form metaphor)? How do I grow that into something using which I could control the capture from within the document?
> 
> If the intent is actually grabbing the video stream, and embedding it in content, here is my proposal:
> 
> <object src="protocol:identifier/for/some/camera/">
>  <param name="aperture-value" value="1.4" />
>  <param name="shutter-speed" value="1/30" />
> </object>
> 
> Implement File and FileReader on the <object> interface.
> 
> <object> (Or even <video>) could implement an interface for setting properties on the device

Just as a reality check, do you really think that a solution involving both <object> and a new URI scheme is simpler and more elegant than one relying on APIs and <video>? Say contrasted to the API in http://www.w3.org/mid/AB072C1D-8194-45A8-968E-5E44D3B8F96E@robineko.com for instance?

--
Robin Berjon
  robineko - hired gun, higher standards
  http://robineko.com/

Received on Saturday, 5 December 2009 02:35:20 UTC