Re: Next steps on Capture API?

Hi,

first congrats on the first public output on the capture API.
Good to see progress there.

I might have missed the place where this had already been
discussed. Anyway. From a user's point of view and my experience
It would be most efficient if the API accepts an object as parameter.
Since there are no named parameters (which would be
ideal) objects are the best replacement and future-proof
especially with an eye on extensibility.
So that the parameters would be passed to the functions
like this:

captureImage({
  onSuccess: function(){},
  onError: function(){},
  timeout: 1000, // in ms
  // ... and whatever is missing can be added, also in later versions
})

Especially useful I find this way since it allows a very generic
way for APIs. It can be used in various places that work
asynchronously and once learned it can easily be reapplied.

just my 2 cents

-- 
cu

Wolfram

http://uxebu.com - the AJAX experts
You need AJAX, RIA, JavaScript and all this modern stuff? We got it!



On Thu, Dec 10, 2009 at 7:28 PM, Tran, Dzung D <dzung.d.tran@intel.com> wrote:
> What I got from the Ajaxian's posting are:
> - API is simple but limited and would like to support for realtime, like video chat
> - Ability to have frequency and waveform data for captured audio similar to Flash.
> - API seems to be designed mainly for mobile devices. It would be nice with API with more capabilities for more powerful devices, so JS can compete with Flash.
>
> Thanks
> Dzung Tran
>
>
> -----Original Message-----
> From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com]
> Sent: Thursday, December 10, 2009 12:53 AM
> To: Tran, Dzung D
> Cc: public-device-apis@w3.org
> Subject: Re: Next steps on Capture API?
>
> On 8.12.2009, at 20.03, ext Tran, Dzung D wrote:
>
>>  I was wondering what would be our next steps in the Capture API.
>> There are lot of discussions going on in the WG. I think we need to
>> come to a consensus, so that we can make some progress on the API.
>>
>> Here is a list of all the discussions so far:
>> 1. Keep it simple and let all the configurations happen natively in
>> the native Camera Application
>> 2. Add configuration options for v1.
>> 2. <input type=...> as the API
>> 3. http://www.w3.org/mid/AB072C1D-8194-45A8-968E-5E44D3B8F96E@robineko.com
>> 4. Adding websocket as a parameter Capture, don't know how this will
>> work.
>> 5. Viewfinder in v1?
>> ...
>> ...anything else that I miss
>
> The Capture API got some public review via Ajaxian (thanks Dion!):
>
> <http://ajaxian.com/archives/w3c-capture-api-our-in-draft>
>
> There are some good comments so I think the spec editors should follow
> up and perhaps invite interested people to join the discussion on this
> list.
>
> -Anssi
>
>

Received on Friday, 11 December 2009 15:24:56 UTC