Re: File API, Editor's Draft II

Arun,

On Jun 18, 2009, at 23:02 , Arun Ranganathan wrote:
>>  - For FileListDataCallback what happens if the user cancels? Do I  
>> get an error? A defined but empty FileList? I have a slight  
>> preference for the latter, but either way the author should be  
>> notified.
> I should make this clearer, but currently if the user cancels, the  
> FileErrorCallback will be called with FileError (with errorCode  
> SECURITY_ERR).  Subsequent suggestions from Anne to NOT match what  
> DOMException does might mean cleaning up my error codes and adding  
> some new ones.

That way works, but indeed having a code other than SECURITY_ERR might  
be more meaningful to the developer.

>>  - General note on asynchronous calls: instead of void, should they  
>> return an opaque token which can be used to cancel the request (or  
>> provide one way or another of doing that, possibly just having  
>> cancel() on the object)? That's available on setTimeout/ 
>> setInterval, and on XHR — it's generally useful.
> Having cancel() on *what objects* exactly?  Also, WindowTimer may  
> not be the best example.

Indeed, WindowTimer might not be emulated. Where cancel() goes depends  
on the request. In this case, I am guessing it would go on the object  
that made the request. So for FileDialog, on FileDialog (this is  
assuming that one would only ever have a single active dialog — this  
should be defined, along with whatever happens if I call open()  
several times in a row).

For getAs* on File it's somewhat more annoying. Given a slow network  
mount, you could easily call getAs* several times before anything  
happened. Would it be expected to return data several times? If the  
callbacks are different objects it could make sense, but if they're  
the same possibly not.

>>  - How do you propose to handle encoding errors? Say a file is UTF8  
>> and I request it as ASCII? Drop what can't be converted? Use a  
>> replacement character? Throw an error?
>>
> In my opinion, charset conversion shouldn't throw any errors, but  
> should try to honor the call as best as possible.  I'll make this  
> clearer.

I am fine with that so long as you specify what the algorithm is to  
handle malformed encodings.

Cheers!

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/

Received on Friday, 19 June 2009 13:16:43 UTC