Re: [File API] feedback on August 1/5 draft

I meant File rather than any, yes. Oops. Also:

On Thu, 06 Aug 2009 20:29:37 +0200, Jonas Sicking <> wrote:
> On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesteren<>  
> wrote:
>> I have not received any feedback on my comments as to why getAsDataURL  
>> is actually needed. I still think it should be dropped.
> Given that the filedata url is very limited in time, getAsDataURL
> still seems useful IMHO.

What is the use case? If the use case is storage I think we should address  
that issue specifically.

And how limited is it exactly? Ian was also suggesting you could increase  
the duration somehow in his original proposal for the new URL scheme. I  
haven't seen any email addressing that point yet.

>> The constants of FileError need to be actually placed on the FileError  
>> object and renumbered as to make sense. They are not DOM exceptions so  
>> it does not make sense to align with that in any way.
> It seems useful to use the same code for people that want to display
> error messages to the user, this way you can either pass the value in
> the DOM event or from an exception to the same function.

If you use the same constant name you can still do that.

> I also can't see a downside to aligning the values?

What if we introduce a new DOM Exception. Will it have to skip these  
numbers? Apart from that, this design is not consistent with similar APIs:  
MediaError and SQLError.

>> Last time I also made comments regarding the details of discovering the  
>> encoding of a file etc. Those still seem to apply.
> Got a pointer to the actual question?  
second bullet point under getAsText(). In particular the way to derive the  
encoding is completely left up to the user agent. I do not think that is  
acceptable as the bug reports we end up getting from that will be very  
confusing and very hard to figure out. Effectively it will mean we'd have  
to reverse engineer the market leader.

Anne van Kesteren

Received on Thursday, 6 August 2009 18:43:24 UTC