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

On Sat, Aug 8, 2009 at 9:37 AM, Garrett Smith<dhtmlkitchen@gmail.com> wrote:
> 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

Skipping this part in order to get to the meat of the discussion which
is the actual proposal. I hope that this is ok. I assure you I read
all of the above.

>> 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.

I so far have not seen any use case that required the need for
multiple callbacks, or indeed where multiple callbacks would even be
useful. The use case from the previous thread seemed to be to hide UI
once file loading was done, no matter if the load succeeded or not.
The easiest way to do that seems to be:

file.getAsBinary(myHandler);

function myHandler(data, error) {
  ... hide UI ...;

  if (error) {
    ... handle error ...
    return;
  }

  ... process data ...
}

If we used a reader (as proposed below) together with progress events,
you'd get code like:

reader = getAReader();
reader.onerror = function() {
  ... handle error ...
}
reader.onload = function() {
  ... process data ...
}
reader.onloadend = function() {
   ... hide UI ...
}
reader.read(file);

I can't really say that this seems like a big benefit.

> 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.

What do you mean by "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.

I'm strongly against this design. See my recent post at
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0547.html
for why. Basically using the same object to both represent a file
resource, as well as a read-request from that resource seems very
prone to bugs.

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

/ Jonas

Received on Tuesday, 11 August 2009 01:49:26 UTC