Re: CaptureAPI initial comments

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