W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: File API Feedback

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 8 Jul 2009 17:05:28 -0700
Message-ID: <63df84f0907081705x688c6cc8l65f0e2f6381111fc@mail.gmail.com>
To: Garrett Smith <dhtmlkitchen@gmail.com>
Cc: arun@mozilla.com, Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
On Wed, Jul 8, 2009 at 2:26 PM, Garrett Smith<dhtmlkitchen@gmail.com> wrote:
> On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sicking<jonas@sicking.cc> wrote:
>> On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smith<dhtmlkitchen@gmail.com> wrote:
>>> On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sicking<jonas@sicking.cc> wrote:
>>>> On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smith<dhtmlkitchen@gmail.com> wrote:
>>>>> On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sicking<jonas@sicking.cc> wrote:
>>>>>> On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smith<dhtmlkitchen@gmail.com> wrote:
>>>>>>>> With that in mind, do you still think it makes sense to have progress
>>>>>>>> events and all the other events you are proposing?
>>>>>>> I've reread my message. The arguments and reasoning given for Events
>>>>>>> seem clear and concise. The argument for Progress Events was
>>>>>>> illustrated with an example and a comparison. What was confusing?
>>>>>> What is the use case for the API you are proposing?
>>>>> The program wants to attach more than one "success" callback at places
>>>>> in the code. The program wants to attach a "timeout" callback, to
>>>>> handle cases where the read operation is too slow.
>>>> But *why* would someone want to attach more than one success callback?
>>> Why would someone want to attach more than one "click" handler to
>>> document? It doesn't really matter why, but it is not hard to imagine
>>> situations.
>>> For example, a notification for all success reads of files to notify
>>> the user of "done", but then specific notifications about the current
>>> file read. Not hard to imagine, but, AISB, it is not necessary to
>>> consider all possible contexts. You have snipped and ignored that and
>>> all other questions. Please don't do that.
>>> AISB, "An asynchronous file read is like an asynchronous XHR, in a
>>> way." It can be desirable to want to have more than one callback for
>>> XHR.
>> I don't know that I've ever seen someone attach more than one
>> eventhandler to an XHR request. In fact, I'm not even sure that IE
>> supports more than one. For the longest time firefox didn't, and I
>> don't think I ever saw a request for attaching more than one.
> Multiple callbacks for XHR are facilitated by custom events. That was
> explained in the "<ajax library aside>" that I wrote.

Sorry, I did not understand how the ajax library aside related to the
original discussion. Reading it again I still don't understand the use
case. I see that you are complaining about the API that the YUI
library has, but I still don't see an explanation of a use case where
you are reading data from a source and wish to have multiple unrelated
listeners notified when that data is read. The way I am reading it you
are saying that you have had this need in the past and that the YUI
library didn't provide that functionality and thus was hard to work
with. Can you explain the situation you were in when you had this

>> Similarly, any API for file access that I have ever seen has only used
>> a single callback. And file system APIs have existed for many many
>> years.
>> UI handling is a lot different from file handling so I don't think the
>> analogy with the "click" event is that strong. The only similarity is
>> the use of a callback.
> The user interacts with the file upload mechanism inside the browser. See?

The user does not interact with the file read API in question here.
The callbacks passed to getAsText/getAsDataURL are called in response
to those calls, not in response to any user interaction.

>> So again, can you give an example of where you'd like two listeners
>> notified with data read from the file?
> What was wrong with the first time I posted it?
> Scroll back up and read:
> | For example, a notification for all success reads of files to notify...
> Read the entire paragraph. Think, write, revise, etc.

I did simply not understand your use case before. I still do not as
described above.

>>> The requirement that determines "inordinately long" comes from a
>>> human, or humans. It is realized in code via a timeout mechanism to
>>> cancel the call. This is prevalent in code that must perform
>>> asynchronously e.g. XHR, animations, etc.
>>> MSDN's XHR and XDR documentation[1] has an example of timeout that is
>>> of particular relevance here; XHR is a data request over http,
>>> FileUpload is a data request in the local network. It is a very common
>>> pattern to have a timeout[2]. Even progress events has a timeout event
>>> (shoehorned into "error")[3].
>> If we add a cancelPendingReads() function (or whatever we decide to
>> call it) then the following code would work to implement timeouts:
>> myFile.dataAsText(dataCallback, errorCallback);
>> timer = setTimeout(function() { myFile.cancelPendingReads(); }, 10000);
>> function dataCallback(data) {
>>  cancelTimeout(timer);
>>  ... do stuff with data ...
>> }
> Yes, using a timeout is very common for code that must perform async,
> AISB. I didn't spell it out with a setTimeout example. It seemed
> obvious.
> The hypothetical example is missing a var declaration, though.

I'm glad we agree on how cancelPendingReads could be used to implement
timeouts then.

>> The two use cases for the timeout property on XDR are:
>> 1. When using synchronous requests. In this case the timeout code
>> above doesn't work since timers don't fire during synchronous reads.
>> 2. As a more convenient API than the above.
> Yes, that one.


>> 1 doesn't apply to the file API since there are no synchronous
>> requests. As for use case 2, I'm not convinced that timeouts for local
>> file reads are common enough that we need to add convenience APIs to
>> deal with it. Especially not in the first revision of the spec.
> I see. Do you anticipate that timeouts will become more common in the
> second revision?

I do not anticipate that timeouts for file reads will be a commonly
used feature no. This due to the fact that reading from local file
systems are very rarely slow enough that timeouts occur.

>> However if others think it's important, we could add a .timeout
>> property on the File object. This would cancel any reads that took
>> longer than the set time and call the error callback.
> Is this a straw poll? I hope not. That sounds like "appeal to
> popularity" and *that* would probably be dilatory.
> Reasoned arguments can and should be assessed aside from the person
> posing them. Reasoned arguments might help avoid generalizing, appeal
> to *, and ad hominem and may help elucidate valuable insight in the
> mind of the readers (the majority of whom will not post their
> thoughts).
> You've already stated that you have objections to a timeout property.
> If you have an opinion on a timeout property, why don't you state it?

As previously stated, I don't think timeouts are something that
developers will want to deal with often enough that we need a
convenience API for it. Thus I think that having a cancelPendingReads
function is enough of an API and that no further features for
implementing timeouts should be added.

>>>> And it gets worse if you want to read the data both as raw data and as
>>>> a data-url. For example in order to process the raw data and send it
>>>> to the server, as well as use the data-url to display a preview using
>>>> an <img>. In that case the code would be more something like:
>>>> file.onsuccess = handleDataUrl;
>>>> file.onerror = genericError;
>>>> file.readAsDataURL();
>>>> function handleDataUrl() {
>>>>  ...
>>>>  file.onsuccess = handleTextDatal;
>>>>  file.readAsText();
>>>> }
>>> Spaghetti code.
>>> The documentation for FileDialog[0] has named the callback parameter
>>> to getAsDataURI as "FileAsText ". From the editor's draft:
>>> | getAsDataURI(in FileAsText callback, [Optional] in FileErrorCallback
>>> errorCallback);
>>> Your example raises a good point. There are two reads, each with
>>> different behavior, but callbacks are a shared behavior. Why not have
>>> a Reader for each behavior?
>>>  var reader = file.textReader;
>>>  reader.success = textReadSuccess;
>>>  reader.read();
>>>  reader = file.uriReader;
>>>  reader.success = uriReadSuccess;
>>>  reader.read();
>>> That makes the individual callbacks a lot simpler. It also provides a
>>> "read" interface that works on any type of Reader. It really makes
>>> more sense when you think about it; a File does not read; a Reader
>>> does.
>> So what if you're reading two parts of the file and want different
>> callbacks. Say for example that you're reading data out of a video
>> file and you want to read both the index of the video to see how long
>> it is, as well as read read the first frame in order to display a
>> preview. Once we have an API for reading ranges of a file, you'd do:
>> file.getDataAtRange(0, 1024, indexHandler, genericError);
>> file.getDataAtRange(4711, 5735, indexHandler, genericError);
>> (the example assumes that the index is located at byte 0, and the
>> first video frame is located at byte 4711).
>> How would you do that using the API you are proposing?
> I wrote a straw man for a Reader, which could use the Events API. In
> the example, a Reader was obtained from a file.
>  var reader = file.textReader;
>  reader.read( file );
> I see you did not respond to that.

My response is what you are replying to. I didn't fully understand
which is why I asked you to explain how to read from two places in the
file at the same time. Based on your explantation below I now
understand what you are proposing. Thank you.

> That proposal may have some problems. The role of a File originally
> included behavior to read itself. I changed that to give the file a
> "reader" property. From a role perspective, that's still a bit off.
> Why should a file "have" a reader? Why cannot a Reader exist on its
> own? That way, it can be passed a File to read, and some other
> arguments.
> Example:
>  reader.read( file );
> and for ranges:-
>  reader.read( file[, start, end);
> Your question:-
> "How would you do that using the API you are proposing?"
> Use an event handler on the Reader. For example:-
> if(typeof FileReader != "undefined" && "BINARY" in FileReader) {
>  reader = FileReader.create( FileReader.BINARY );
>  if(reader != null) { // Reader was created.
>    reader.addEventListener("success", func, false);
>    reader.read(file, i, j);
>  }
> }
> Wrinkly, maybe but the gist.

I understand. I would say that I think the API in the current proposal
is better due to its simplicity.

> Messages I have posted in this thread raised points and questions that
> your message follow-ups have ignored and/or snipped. AISB, and again,
> please don't do that.

Sorry, I did not mean to ignore anything. I only responded to the
parts of your message that I didn't understand or that I had further
questions on. In this message I have not removed anything as to avoid
you thinking that anything got ignored.

> Regards,
> Garrett

/ Jonas
Received on Thursday, 9 July 2009 00:06:29 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:17 UTC