- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 02 Dec 2009 11:41:43 +0100
- To: "Tran, Dzung D" <dzung.d.tran@intel.com>
- Cc: public-device-apis <public-device-apis@w3.org>
Le mardi 01 décembre 2009 à 19:50 -0800, Tran, Dzung D a écrit : > It is checked in to CVS as stated below. There is some formatting > problems, which I am strap for time to figure out right now. > http://dev.w3.org/2009/dap/camera/Overview.html 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); • 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? • 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; • 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 • 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) • I’m not sure there is much points in defining MediaArray; I think we ought to refer directly to sequence<MediaData>; in any case, it should be renamed to MediaSequence if we keep it (array and sequences are distinct in WebIDL) • the current API hangs off of navigator.device (at least in the example) — I have added an an issue in the document that this interface would need to be defined somewhere Dom
Received on Wednesday, 2 December 2009 10:41:54 UTC