- From: Jim Barnett <Jim.Barnett@genesyslab.com>
- Date: Sat, 8 Dec 2012 15:01:42 +0000
- To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On Dec 8, 2012, at 1:57 AM, "Stefan Hakansson LK" <stefan.lk.hakansson@ericsson.com> wrote: > On 12/07/2012 04:25 PM, Jim Barnett wrote: >> As I understand Anant’s proposal, the APIs will raise exceptions only >> for problems that can be detected at call time – so things like arg type >> mismatch, etc. Other errors will be signaled by raising error events. >> >> My first concern is coming up with a list of the errors we want to >> define. Once we do that, we can define types and attributes for them >> etc. (We also have to make sure that the exceptions make it into the >> spec.) So here’s a rather haphazard start at listing (some of) the >> errors we will need. >> >> In the current gUM draft, the only error I see is >> NavigatorUserMediaError. It has a ‘code’ attribute, and the only value >> defined for it is 1, meaning “permission denied”. Now, if we include >> mandatory constraints, another kind of error is possible, namely that no >> device satisfies the constraints. > > Is not this problem there even without mandatory constraints? Perhaps there is no device of the indicated type (e.g. no camera), and the user had no suitable file that he/she would allow as source. It's a pedantic point, but I take this to mean that the device type is an implicitly mandatory constraint. > Anyway, should not the result also be that the track(s) the device is meant to serve go to state "ended"? > >> However, to avoid fingerprinting, we >> may want to use the same “permission denied” code for a failed >> constraint. That way the app won’t know whether the user refused >> permission for the device, or simply didn’t have it. > > In v5, we also have the error events "constraintsuccess" and "constrainterror" to signal if the application of a changed constraint was successful or no Good, I'll add constrainterror to the list. > >> >> On the other hand, if we go the route of allowing apps to build dummy >> tracks and assign them properties, so that they can be used for >> negotiation, we have to deal with the errors that can arise when the >> track is connected to a source device that lacks the specified property. >> This is really the same sort of error as the failure of a mandatory >> constraint. Do we again want to use “permission denied” for this case? >> >> Also, what happens if a device that is being used is disconnected or >> somehow fails? Is that an error that we should detect and signal? Is >> that a new ‘device-unavailable’ error? > > So far, the "ended" event on the corresponding MediaStreamTrack has been intended to serve this purpose. The app won't know if it is an error or if the device was unplugged on purpose, but it will get to know that the track has ended permanently for some reason and can take actions. Ok, so there is no error needed here. >> >> On the recording side, we have one set of well-defined errors, which are >> currently called “recordingwarning” (we may want to change the name). >> This event catches state errors, for example when the app calls >> stopRecording when recording hasn’t been started. Since these events >> are really catching errors in programming logic, we can define all the >> places that they occur. The main question is what kind of data they >> should have. (Should they contain a field indicating the current state, >> or one indicating what the state would have to be for the command to be >> legal?) >> >> The set of ‘recordingerror’s is much messier. This indicates that >> something has gone wrong at the platform-level. Given the wide variety >> of platforms webRTC can end up running on, it’s not clear to me how >> precisely we can define this set. Among possible errors are: >> >> ·You’ve asked for an unsupported format >> >> ·You’ve asked for an impossible combination of formats (I’m assuming >> that container formats put restrictions on the audio and video formats >> that they embed) >> >> ·You’ve asked for a buffer size that I don’t support (too big or too small) >> >> ·Out of memory >> >> ·You’ve added a track while recording is going on, and the container >> format doesn’t support that (this could be treated as a recordingwarning >> as well, but it doesn’t look much like a state error) >> >> ·Hardware or software effecting the transcoding (something’s gone wrong >> and the UA can no longer produce the specified format) >> >> ·??? I’m sure that there are all sorts of other problems that I haven’t >> thought of. >> >> Please send me comments and let me know what else you can think of. >> Once we’ve had enough discussion, I’ll send around the full list of >> errors, and we can discuss types, attributes, etc. >> >> -Jim > >
Received on Saturday, 8 December 2012 15:02:11 UTC