Re: New FileAPI Draft | was Re: FileAPI feedback

A few comments:

Need to specify that all getAsX functions call the callback
*asynchronously*. Also need to integrate this with the HTML5 event
loop.

getAsBinary should be called getAsBinaryString so that once we have a
BinaryArray or some such we can add a getAsBinary that truly returns
binary data.

Need to specify the actual encoding for getAsBinary, i.e. that each
character holds one byte, valued between 0-255.

Obviously the filedata scheme needs to be defined in greater detail.

What's the use-case for getAsBase64?

splice should synchronously return a new FileData object. No need for
asynchronous callback since no IO occurs.

getAsBinaryString could take two optional |start| and |length|
arguments to avoid having to use splice to read parts of a file.

/ Jonas

On Tue, Aug 4, 2009 at 6:55 PM, Arun Ranganathan<arun@mozilla.com> wrote:
> I have updated the draft of the File API, and welcome more review.  Note
> that it is no longer called "FileUpload" since this term has become
> misleading.
>
> In particular, here are some of the issues addressed (and some not):
>
>> Any reason you're using an XHTML file to edit this?  Also, the indentation
>> is awkward.
>
> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
>
>> For what concerns the "file as URI" feature:
>>What about reusing the "cid" scheme?
>
> After having looked at the RFCs for cid and mid schemes, I don't think the
> cid scheme is appropriate for our use case, since it is tightly tied to the
> notion of message body, which isn't necessarily true in all cases of file
> data.
>
> I have a proposal in this draft for the "file as URL" proposal (originally
> broached in IRC, but which has seen some discussion on the listserv).  I'd
> welcome feedback on it, especially the processing model for these URLs.  A
> simple ABNF using UUIDs as unique identifiers has been proposed here.
>
>> File API should probably have some way to get only parts of the file.
>
> This has been added as a new method.  Feedback welcome!
>
>>[The existing design] limits the number of callbacks to one. That one
>> callback
>>can only be added in the invocation to read.
>>Instead, allow multiple callbacks to be added with the DOM Events API
>
> While this was an intriguing suggestion (and seemed like it was a more
> powerful programming model), I wasn't convinced that it was needed for the
> File API.  It did lead to a more complicated model that didn't seem to fully
> justify the power.  However, I did study subsequent use cases, and
> eliminated error callbacks, allowing callbacks themselves to handle error
> conditions.  Also, I introduced a cancelReads( ) which can be used with
> timeouts.  I'm not convinced that an event model is necessary for
> asynchronous data accessors on file data; DOM events aren't useful in all
> cases.  It's also worth nothing that the File API in general may be subject
> to further iteration in the Device API WG, which may introduce notions of
> "write" APIs.
>
>>Note of course that whatever API supports ranges needs to ensure that
>>the data isn't forcibly coerced into valid Unicode, as the underlying
>>data for an image can include all sorts of patterns which aren't valid
>>UTF8/16/....
>
> It was clear that getAsText was insufficient, so more asynchronous data
> accessor methods have been added.
>
>> I think FileDialog is a bad idea. We already have UI for selecting
>> multiple files: <input type=file
>>multiple>.
>
> This has now been eliminated from this draft.  I'm keen to move towards
> fpwd, and it seemed that FileDialog was needlessly controversial.  I think
> it still is useful, and think it could be added later.
>
> -- A*
>
>

Received on Thursday, 6 August 2009 01:56:28 UTC