Re: [MEDIA_PIPELINE_TF] HTML media errors

Hi Mark,

Did you look at the XMLHttpRequest  way of dealing with http
error/response codes?
http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute

I would think that if we design in-depth error handling for media
elements, it should be modeled on this existing way of dealing with
error codes.

It has the following IDL:
  // response
  readonly attribute unsigned short status;
  readonly attribute DOMString statusText;
  DOMString getResponseHeader(DOMString header);
  DOMString getAllResponseHeaders();
  readonly attribute DOMString responseText;
  readonly attribute Document responseXML;

This is of course just for HTTP, but it should be possible to adapt
this to any protocol and then just add an indicator for what protocol
had a problem and gave these results.

Cheers,
Silvia.


On Sat, Nov 5, 2011 at 5:50 AM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Nov 4, 2011, at 11:16 AM, Jan Lindquist wrote:
>
>> Hi,
>>
>> Adding the granular aspect is very useful. My suggestion is to simply add a reason attribute to give the additional details. I am concerned with possible too many layers. You have 3 levels with this proposal, general error, http error and http response code. Or maybe I misunderstood.
>
> If you mean a free-format "reason" string field, this is very unlikely to fly in HTML - I floated it in the Content Protection breakout and got a pretty negative response from the HTML people there.
>
> The three layers are (i) the existing error code (~3 values) (ii) more specific code for network errors (iii) http error code in the specific case of http errors.
>
> Layers are good for errors, because scripts can choose what level of detail they are interested in.
>
>>
>> The question is what can be done with the error reason. Does it need to be formalized so the application can take different actions based on reason or is it simply to facilitate support. I believe the intention is the later, simply facilitate support. So simply a string and not necessarily code is needed.
>
> I believe we need specific well-defined values to get it into HTML.
>
> ...Mark
>
>
>>
>> Regards,
>> JanL
>>
>> ________________________________
>> From: Vickers, Mark [Mark_Vickers@cable.comcast.com]
>> Sent: Friday, November 04, 2011 6:05 PM
>> To: Mark Watson
>> Cc: public-web-and-tv@w3.org WG
>> Subject: Re: [MEDIA_PIPELINE_TF] HTML media errors
>>
>> This is a great start. The backwards compatibility is good.
>>
>> Should we reference to the IETF protocol documents which define the errors (DNS, TCP, TLS, HTTP, ...) for the error code list and meanings?
>>
>> Also, how were these errors chosen out of all errors defined in those specs?
>>
>> Thanks,
>> mav
>>
>> On Nov 4, 2011, at 9:05 AM, Mark Watson wrote:
>>
>> All,
>>
>> I put up a proposal for additional network-related errors at http://www.w3.org/2011/webtv/wiki/MPTF/HTML_Error_codes
>>
>> I would hope these would be uncontroversial and so could be added to one of the existing LC1 bugs as a concrete proposal for discussion.
>>
>> I suggest we discuss these a little on this list and then link them from the appropriate bug.
>>
>> ...Mark
>>
>>
>
>
>

Received on Friday, 4 November 2011 20:15:37 UTC