- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Wed, 16 Jan 2013 00:08:41 +0000
- To: Jim Barnett <Jim.Barnett@genesyslab.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <9768D477C67135458BF978A45BCF9B3853B75619@TK5EX14MBXW605.wingroup.windeploy.ntde>
I'm still thinking about the user consent question. For the settable parameters, I think it makes sense to follow the constraints pattern in the other spec-readable properties on the Recorder with a mechanism for overlaying constraints on top of that. From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com] Sent: Tuesday, January 15, 2013 12:26 PM To: public-media-capture@w3.org Subject: user permission for recording? We haven't discussed whether user consent is required for recording. In general, I would think that users would want to know when they are being recorded and would want to be able to block recording. (Of course, the user can't be guaranteed that the other end isn't recording the call, but that's the case on phone calls today.) So: 1. Should user consent be required for recording? 2. If so, when should it be given? As part of the initial call to gUM? When recording actually starts? (via another call to gUM or in the Recorder constructor?). Also, we have identified 3 settable parameters for recording so far: the Mime type, video height, and video width. None of these function as constraints that can be used to select the appropriate 'device', so does it make sense to use the constraint structure to specify them? Wouldn't it be simpler to let them be settable attributes of the Recorder class? (We would still need a getCapabilities call to determine what the legal values are, and we wouldn't allow the values to be changed while recording was going on.) - Jim
Received on Wednesday, 16 January 2013 00:09:25 UTC