- From: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
- Date: Wed, 30 Nov 2011 13:00:05 +0100
- To: Robin Berjon <robin@berjon.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
+1 to drop the success / error callback using one of the mechanisms proposed by Robin El 30/11/11 12:38, "Robin Berjon" <robin@berjon.com> escribió: >Hi, > >On Nov 30, 2011, at 12:05 , Stefan Håkansson LK wrote: >> to get started, a first Editor's draft (based on getUserMedia in the >>WebRTC 1.0 document) has been created: >><http://dev.w3.org/2011/webrtc/editor/getusermedia.html>. >> >> The initial editors are Dan Burnett and Anant Narayanan. > >Excellent! Thanks for getting this ball rolling. Some quick notes follow >(in no order whatsoever). > >We will need to sort out the boilerplate so that it matches joint IPR >coverage. Not something we need to do now but we'll need to handle it >before publication. > >Why is the title "getusermedia" when the method is getUserMedia? Perhaps >a simpler, shorter title would work better. I don't want to bikeshed and >think the editors should make the call, but maybe Media Capture API, or >Local Media Capture API? > >getUserMedia() uses the success/error callback approach, which is >increasingly disliked. I would suggest either returning an object on >which handlers can be set: > >var um = navigator.getUserMedia(options); >um.onsuccess = function (stream) { ... }; >um.onerror = function (err) { ... }; >um.start(); > >Or the Node-style compound callback: > >navigator.getUserMedia(options, function (err, stream) {...}); > >I personally have a preference for the latter, but that is naturally up >for discussion. > >Do we expect LocalMediaStream to remain outside of this spec? I don't >have an opinion on this, I'm just curious about the thinking behind the >cut. > >One issue that remains fully open is the capture of stills. A typical use >case would be to acquire the video feed from a camera in order for it to >serve as a viewfinder in the application, and then be able to trigger a >still capture from the device. Note that frame-grabbing is not at all an >option here since you will never get anywhere near the quality that the >device can produce. > >-- >Robin Berjon - http://berjon.com/ - @robinberjon > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Received on Wednesday, 30 November 2011 12:00:33 UTC