Re: New FileAPI Draft | was Re: FileAPI feedback

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.
>

http://www.thefreedictionary.com/intrigue

You've chosen to sit out the entire discussion of reading a file,
your conclusion that the original design you drafted is less complex
has not been demonstrated.

What you have demonstrated seems to be nothing more than self-superiority.

Please show the subsequent use cases you've studied and please do
publish your studies.

>>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.

FileDialog can be added later or created as an entirely separate
interface or specification.

I did, however, find this mornings tweet-:

<audio><video><disco>

- to make a great point about HTML 5.

Garrett

Received on Wednesday, 5 August 2009 07:48:07 UTC