Re: File API Feedback

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?

What do you mean by timeout? That the OS thinks that accessing the
file takes so long that it aborts and returns a failure? Or that the
page thinks it takes too long?

If the former, there is already an error callback which would be
called on timeout. If the latter, that seems like a decision the page
makes and so no event would be involved.

However having a function that allows you to cancel any pending read,
for example if the read takes too long or is for some other reason no
longer relevant, seems like it might be worth perusing.

Something like FileData.cancelPendingReads() seems like the simplest solution.

Though technically the same effect can already be archived if the
implementation simply ignores the callback when it arrives. I'm not
sure it's worth adding this API unless it turns out it's something
that sites actually needs.

>> I agree that what
>> you are proposing allows for a lot of flexibility, but it also results
>> in an API that is more complex.
>
> Hardly. If no new messages (callbacks) are created, the design
> separates messaging and behavior.
>
> How is this:-
>
> file.onsuccess = genericSuccess;
> file.onerror = genericError;
> file.read();
>
> More complicated than:-
>
> file.read(genericSuccess, genericError);

This seems more complicated to me. It's three times as many lines of code.

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();
}

This is significantly more complicated than:

file.getAsDataUrl(handleDataUrl, genericError);
file.getAsText(handleText, genericError);

/ Jonas

Received on Wednesday, 1 July 2009 02:37:52 UTC