Re: [File API] events vs callbacks (was: Re: New FileAPI Draft | was Re: FileAPI feedback)

On Thu, Aug 6, 2009 at 11:31 AM, Jonas Sicking<jonas@sicking.cc> wrote:
> On Wed, Aug 5, 2009 at 4:26 AM, Anne van Kesteren<annevk@opera.com> wrote:
>> On Wed, 05 Aug 2009 10:04:28 +0200, Arun Ranganathan <arun@mozilla.com>
>> wrote:
>>>
>>> In the case of file read APIs, simply getting the data asynchronously is
>>> more convenient than using events.  There is no intrigue at work here,
>>> merely disagreement.
>>

Who said "getting data asynchronuosly" is less convenient than "using
events"? I am not sure what that really means, but I am pretty sure
this is not a debate of "using events" vs. "getting data
asynchronously".

Arun also argued previously: "Callbacks are used so that these APIs
can behave asynchronously." The callback parameter has nothing
whatsoever to do with the API being asynchronous. How the callback is
registered is a design decision.

It was determined and agreed that reading a file should be
asynchronous. We should all be on the same page now.

Event callbacks are asynchronous. So, it is not a matter of arguing
"synchronous events" with "asynchronous callback".

Problems with the existing design were already explained in the other
thread. Some of those problems were not acknowledged by the author.
There is not a consensus.

I would like to register a Formal Objection.

The File API design does not provide for standard callback
registration, but instead uses its own callback registration
mechanism. This limits the flexibility of implementation code and
limits extensibility of the API.

>> I could imagine that for reading data you might want to have events though
>> so that in the future we can introduce progress events if that is found
>> necessary. E.g. if the actual file is not on the same computer as where the
>> user selected it.
>

An API should generally be extensible.

Problem: The File API couples the call to read with the callback.
This violates OCP.

This is easily achievable by decouple the call to "read" from the
notification that the reading has completed.

The way to solve this problem entails the reader implementing either:
  1) DOM Events
  2) DOM Event handler properties

> Do you have a proposal for what this would look  I'm not excited
> about creating something that's significantly more complex than the
> current API.
>

Removing the callback parameter and using a Reader was proposed in
that other thread. While it was argued that it had fewer LOC in the
simplest cases, it wasn't ever demonstrated as being more complicated.

The current possibility is to have just a callback:-

file.getAsDataURL(handleURL);

- and then check the status to see if it was successful.

How to implement multiple callbacks with that?

Multiple callbacks can be implemented with the current draft proposal,
e.g. ala "file.read( callWhenDone )", but not without a good amount of
work. It would entail the program to create its own Reader that is
itself an EventPublisher[1] Depending on the situation, that could be
elegant or could be extra plumbing.

The proposed Reader solution:

  var reader = getAReader(); // etc.
  reader.oncomplete = readDone;
  reader.read( file );

This allows new features to be added, allowing forwards changes
without changing existing features.  This also has a benefit of
providing an Interface (Reader) that 1) reads, and 2) fires events.
The reader could be any sort of reader.

Using a Reader decouples the type of read from the file object.

The other proposed solution was to have the events on the file, not as
a separate Reader.

file.oncomplete = contentsRead;
file.readAsDataUrl();
file.readAsText();

That puts the context on the file. This means the callback must check
the result of the type of read. In the example above, "contentsRead"
would have to know something about the data read (is it a URL or
Text?) and would end up having "if else" statements that call other
functions. This was provided in Jonas' example of reading file raw
data and as a data-url.

> / Jonas
>

Regards,

Garrett
[1] An EventPublisher keeps track of subscribers (other callbacks),
provides its own mechanism for registration), and fires events.

Received on Saturday, 8 August 2009 16:38:16 UTC