RE: Move to de-facto error reporting

I would also observe that in gUM the 'failure' case is not an error.  The user said "no" and that's allowed and expected behavior.  I think it's completely legitimate to have a different paradigm for these cases as opposed to "run, there's smoke coming out of the back of the computer".  

- Jim

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Friday, December 21, 2012 6:41 PM
To: public-media-capture@w3.org
Subject: Re: Move to de-facto error reporting

(top-posting again)
a huge difference in the IndexedDB model and the callback model we're currently using is the use of an "action object".

IndexedDB operations return (synchronously) an object that represents the request - it's this object that gets the success or error events fired at it.

In GetUserMedia, the difference is at its most stark (at least in the current version): There is no immediate object; success and callback functions are passed TO the operation, and called appropriately.

As usual, I'm quite hesitant to do major redesign on a model that's been stable for a year without having the very important question answered:

* What can we do in the new model that we were prevented from doing in the old? *

I see consistency as a Good Thing. But consistency that requires every application programmer using these interfaces to *redesign*, not just patch up, their applications is a quite high cost to pay.


On 12/21/2012 07:47 PM, Travis Leithead wrote:
>> From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>> Travis,
>>
>> (sorry for the top-posting) at least on a high level I agree fully 
>> (and I think I have said on occasions that we should use DOMErrors).
>>
>> Though, I know that it has been argued there are occasions when you 
>> need to know directly if something succeeded or not. One example that 
>> has been brought up is setLocal/Remote. You would like to know if the 
>> application of the offer/answer was successful or not before sending 
>> it off to the peer's UA. I think that is the reason success and error 
>> callbacks are used there rather than error events (since it would be 
>> undefined how long you would wait for a error event before 
>> considering it a success).
>>
>> I don't know to what extent this can be worked around, as said I 
>> fully support aligning to DOMErrors as far as possibly - but so far 
>> that we lose functionality.
>>
>> Stefan
> Actually, this is not a new problem. Applications have a similar need when interacting with Indexed Db--for example, then want to start a request, then once they know a part of the request has succeeded, then the start the next conditional part of the request, etc. For this purpose IndexedDb also includes an onsuccess ("success") event that fires on the request. Note, that due to the asynchronicity of various IndexedDB requests, each request returns a request object upon which the onsuccess handler can be registered. This is very similar to the "promises" async programming pattern.
>
> I'm not offering up a solution to that problem, because I don't think it's trivial. Keeping a success callback might be the right thing to do in this case, I'm not sure.
>
>
>> On 2012-12-20 22:05, Travis Leithead wrote:
>>> [Cross-posting for visibility]
>>>
>>> I'd like to suggest that we refactor our error handling behavior 
>>> among
>> all three WebRTC primary specs: WebRTC, Media Capture and Streams, 
>> and the Recording API. I'd like to move to the error model in use in 
>> DOM4/File API/IndexedDb and HTML5's Media Elements.
>>> I pointed out in another thread
>> (http://lists.w3.org/Archives/Public/public-media-
>> capture/2012Dec/0163.html) that the WebRTC/Media Capture/Recording 
>> API specs are using an error-notification model that is not based on 
>> the model being used by other specs in the WebApps and HTML working 
>> group-namely we're basing our model off of the Geolocation spec's 
>> pattern, rather than that of the DOM4/File API/IndexedDb/HTML5 pattern.
>>> The new pattern has only been around for a little over a year, so I
>> don't think we can be blamed for not noticing/applying it earlier.
>>> To summarize the differences in the patterns:
>>> * The Geolocation pattern is to have a callback/event which is 
>>> provided
>> with an Error object which has a field which reports the name of the 
>> error (the error name and the exception names are usually the same).
>>> * The new pattern is to use a DOMError-based "error" attribute on 
>>> the
>> target object and use a normal vanilla "error" event to raise 
>> awareness that this state-attribute has been set.
>>> Here's how the Geolocation pattern plays out in the WebRTC, Media
>> Capture and Streams, and Recording API proposals:
>>> An example from WebRTC's doc: RTCPeerConnection.createOffer says:
>>> void createOffer(RTCSessionDescriptionCallback successCallback,
>>>                    RTCPeerConnectionErrorCallback failureCallback, 
>>> ...)
>>>
>>> Where RTCPeerConnectionErrorCallback will get an RTCError, and the
>> RTCError has a "name" and a "message"
>>> This pattern is repeated elsewhere in getUserMedia:
>> NavigatorUserMediaErrorCallback has a NavigatorUserMediaError with a 
>> "code".
>>> and now in the Recording Proposal [1]: onrecordingerror gets a
>> RecordingError object which has a "name" and a "message"
>>> As you can see, this pattern needlessly complicates the web platform 
>>> by
>> having a bunch of objects that basically provide the exact same 
>> functionality.
>>> In the WebApps and HTML working groups, they have also seen this
>> proliferation, and decided to unify under a new pattern for providing 
>> asynchronous error notifications. In the new pattern, there is an 
>> error state which is maintained by an object, and an event that fires 
>> to inform the application to check the object's error state.
>>> DOMError is the object that consolidates the functionality of 
>>> RTCError,
>> NavigatorUserMediaError, and RecordingError. It also consolidated 
>> similiarly proposed error objects in the File API, Indexed Db specs. 
>> The DOMError object is defined in DOM4 [2].
>>> Here's how it looks in FileReader [3]:
>>>
>>> interface FileReader {
>>>      readonly attribute DOMError error;
>>>               attribute Function? onerror;
>>>      ...
>>> }
>>>
>>> Here it is for Indexed Db transaction request objects [4]:
>>>
>>> interface IDBRequest {
>>>      readonly attribute DOMError error;
>>>               attribute Function? onerror;
>>>      ...
>>> }
>>>
>>> Here's how it's used in HTML5 [5] (which uses codes, unfortunately, 
>>> so
>> it's based on the model before DOMError came around, and has now been 
>> widely implemented so it can't be changed):
>>> Interface HTMLMediaElement {
>>>      readonly attribute MediaError? error;
>>>      ...
>>> }
>>> And an onerror handler defined in the super-interface HTMLElement.
>>>
>>> I'd like to propose that we re-use this concept for our specs. The
>> specific changes would apply to:
>>> WebRTC spec:
>>> * RTCPeerConnection interface would get a DOMError error attribute, 
>>> and
>> an onerror EventHandler. The following APIs would need to be 
>> adjusted/simplified to remove the failureCallback parameter:
>>>     - createOffer
>>>     - createAnswer
>>>     - setLocalDescription
>>>     - setRemoteDescription
>>>     - getStats
>>>
>>> Media Capture and Streams spec:
>>> * MediaStream interface would get a DOMError error attribute, and an
>> onerror EventHandler. The Following APIs would be adjusted to remove 
>> the
>> errorCallback:
>>>     - getUserMedia
>>>
>>> Recording API spec:
>>> * MediaRecorder interface would get a DOMError error attribute. This
>> interface already has an onrecordingerror handler, and it would be 
>> simplified to not carry the error state and behave like other normal 
>> event objects.
>>>
>>> [1] http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-
>> capture/RecordingProposal.html
>>> [2] 
>>> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-
>> domerror
>>> [3] http://dev.w3.org/2006/webapi/FileAPI/#dfn-error-codes
>>> [4] 
>>> http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#request-
>> api
>>> [5] http://www.w3.org/html/wg/drafts/html/master/embedded-content-
>> 0.html#mediaerror
>>>
>

Received on Friday, 21 December 2012 23:47:19 UTC