Re: New FileAPI Draft | was Re: FileAPI feedback

Oh, getAsURL should also be synchronous since no IO is occurring.

/ Jonas

On Wed, Aug 5, 2009 at 6:55 PM, Jonas Sicking<jonas@sicking.cc> wrote:
> 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:57:31 UTC