Re: File API Feedback

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.

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

?

Thus I think we should stick with the
> current API unless you have use cases in mind that only works in the
> API you are proposing.
>
I disagree. Adding events simplifies the readXXX() methods to just
read. (Did you notice how the two read methods contain a long
copy'n'paste?)

When the file read is in progress, but before it is complete, how will
the user know that reading is in progress?

What if reading the file takes an inordinately long time? This could
happen, for example, if the machine that is being read from slows down
(archiving). That problem is solvable by wrapping a read request with
function that calls setTimeout(cancelRead, t).

When reading one large file (a movie, for example), how can a program
provide notification of progress of the read?

Regardless, it is not necessary to consider all possible contexts,
etc. Adding a callback is separate from requesting a read. The
expectations of the readXXX methods should be simple.

Perhaps one day, someone will use this API build a usable web-based
email application. I would like to use that, as a user.

Garrett

Received on Wednesday, 1 July 2009 01:14:27 UTC