W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Re: CaptureAPI initial comments

From: Ilkka Oksanen <Ilkka.Oksanen@nokia.com>
Date: Thu, 25 Mar 2010 13:08:22 +0200
Message-ID: <4BAB4426.2060304@nokia.com>
To: ext Rik Sagar <org.whatwg@sagar.org>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Hi Rik,

Thanks for you comments. They will be considered.

On 24.03.10 02:32, ext Rik Sagar wrote:
>  We need to consider either a richer vocabulary to specify the
>  encoding (and allow an application to enumerate the encoding
>  options).  For example, something including bitrates, audio channels,
>  codecs, in addition to a simplified API that is at a higher level,
>  e.g., compression=low|medium|high
>

Do you have any existing vocabulary in mind which we could re-use here?
I think specifying new one from scratch might not be very
straightforward. Maybe single compression option would suffice. It
could be a hint for the native implementation either to optimize for
quality or file size. I believe the application is mostly interested on
file size, especially in cases where media file is uploaded to a remote
server.

>  CAPTURE IMAGE CALLBACKS
>
>  The captureImage() call takes callbacks for success and error.  In a
>   camera API I implemented recently I went with the event listener
>  model, i.e., camera..addEventListener('save', callback, bubble);
>

Capture API follows the same convention that is used in the other DAP APIs
including System Info, Calendar, Contacts, Gallery, and Messaging. In
general DOM events have also been considered. The problem identified was
options parameter that can't be part of addEventListener(). How did you
solve this in your API?

             -ilkka
Received on Thursday, 25 March 2010 11:09:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:07 GMT