W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [File API] Issue 182 about OperationNotAllowed

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 4 Oct 2011 02:29:21 +0000 (UTC)
To: Jonas Sicking <jonas@sicking.cc>
Cc: Arun Ranganathan <arun@mozilla.com>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.64.1110040223010.20981@ps20323.dreamhostps.com>
On Mon, 3 Oct 2011, Jonas Sicking wrote:
> 
> So MediaError is exactly the type of thing that I'm talking about that 
> we might want to move into the DOM4 spec. We have the same thing in the 
> File API spec. The FileError interface is just a plain object with a 
> single .code property. We're planning on moving that to expose a .name 
> property instead which will contain the same strings as 
> DOMException.name.
> 
> I'm thinking we should do the same thing for IndexedDB too.
> 
> So having a central DOMError interface which we can reuse for all places 
> which expose asynchronous errors would be helpful. If specifications 
> want to add more information than what's defined by DOM4, they can 
> always extend the interface.

Oh, I don't think I'd use a central error interface for 
HTMLMediaElement.error. I don't really see much value to it. Going forward 
I see us putting all kinds of media-specific stuff in there like the name 
of the codec, the frame at which the error occurred, or other such things. 
Those wouldn't make sense in a FileError equivalent. In a FileError I 
would imagine seeing such things as a reference to the relevant File 
object, or a byte offset into where the read error occurred, or whatnot.

We could have them all inherit from a common Error interface, but honestly 
that doesn't get us much.

I agree that we should try to be consistent going forward. It's not a huge 
issue though. I don't mind adding a "name" attribute to MediaError at some 
point if that's the way other such interfaces go. I don't expect most 
authors to ever interact with this part of the API so it's not a high 
priority. (First we have to add video metrics, for instance. In some 
manner that doesn't lead to helping fingerprinters...)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 4 October 2011 02:32:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT