W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

Re: First stab at the Capture API (aka Camera API)

From: Robin Berjon <robin@robineko.com>
Date: Wed, 2 Dec 2009 13:21:00 +0100
Cc: "Tran, Dzung D" <dzung.d.tran@intel.com>, public-device-apis <public-device-apis@w3.org>
Message-Id: <D4D29B50-E4D2-481B-95EE-492712F37D50@robineko.com>
To: Dominique Hazael-Massieux <dom@w3.org>
On Dec 2, 2009, at 11:41 , Dominique Hazael-Massieux wrote:
> Some  thoughts and questions on the current proposal:
> • if I understand it correctly, the current API assumes that the capture
> activity is done separately from the Web environment — in particular,
> the fact that the callbacks return with an array of results, and the
> existence of the limit parameter, suggests that all the expected
> materials is returned at once; this seems to entirely prevent a browser
> from embedding the capture activity inside the viewport (where
> presumably the capture could be done in several rows);

My proposal here would be to convince ourselves (see other related post) that we can grow this API to support viewfinder embedding, but leave it for later.

> • it’s not clear if the limit parameter is binding — can a developer
> assume that the MediaArray she gets from the callback function will have
> a length inferior or equal to limit?

I agree that if it's there it should be binding. My question is: is this implementable on existing platforms?

> • the limit and duration parameters are non-optional; it’s not clear how
> you would allow the user to capture as many and as long media as he
> would need;

+1. We'll also need indeterminate duration if we want to stream in the future.

> • duration is currently a double, counted in seconds; I think it would
> make more sense to count in miliseconds (or microseconds?) and possibly
> make it an unsigned long long

+1 to milliseconds. I don't think that microsecond is useful given the fps that we're talking about here :)

> • I think MediaData should have an (optional?) timestamp parameter that
> tells the time and date at which the capture was made — this enables
> interesting use cases (e.g. sorting a sequence of media by the time they
> were taken; geo-tagging media by relating the timestamp to the ones
> recorded by the geolocation API)

That's a really good addition. Note that WebIDL has added a native Date type (which maps to JS Date).

Robin Berjon
  robineko — hired gun, higher standards
Received on Wednesday, 2 December 2009 12:21:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC