- From: Robin Berjon <robin@robineko.com>
- Date: Wed, 2 Dec 2009 13:21:00 +0100
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: "Tran, Dzung D" <dzung.d.tran@intel.com>, public-device-apis <public-device-apis@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. > its 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; its 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 http://robineko.com/
Received on Wednesday, 2 December 2009 12:21:29 UTC