Re: New FileAPI Draft | was Re: FileAPI feedback

On Wed, Aug 5, 2009 at 8:08 PM, Garrett Smith <dhtmlkitchen@gmail.com>wrote:

> On Wed, Aug 5, 2009 at 1:04 AM, Arun Ranganathan<arun@mozilla.com> wrote:
> > Garrett Smith wrote:
> >>
> >> Please show the subsequent use cases you've studied and please do
> >> publish your studies.
> >>
> >>
> >
> > What I meant by "use cases" was this exchange:
> >
> > http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0371.html
> >
> > http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0457.html
> >
>
> Those are the discussions of Events that you did not participate in.
> Where is the complexity study?
>
> > In the case of changing UI indicators, using a common codepath for
> success
> > as well as errors seemed more useful than multiple error callbacks.
>
> Multiple error callbacks? Who brought that up? Are you making a Straw Man?
>
> > 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.
> >
>
> Is it? In reading that discussion, I see no disagreement from you
> whatsoever.
>
> I see that you posted this new thread. You said you "studied" the use
> cases and that your original design was best. We still have no
> evidence that any studying has taken place. Please post the studies so
> that they can be understood.
>
> The route you chose makes a permanent design decision.  Once done, it
> can not be undone. If it goes through as is, the best case at that
> point would be to start over.
>
> I am not going to argue with hand-waving summations or the "multiple
> error handlers" straw man.
>
>
> Garrett


I probably have no understanding of the issue but casually glancing at
the discussion links above, can't you solve the multiple callback issue
by wrapping the callback in JavaScript?

If I understand correctly, a File is not an element nor is it attached to
the DOM so some random JavaScript can not do something like
document.getElementsByTagName('File');

In the DOM case multiple callbacks per event make some sense because
2 different pieces of code can find the same elements but in the File case
only
code can create a File object, some other random code can't go
searching for that object. That means the code that created the File object
can manage it however it sees fit including wrapping the entire thing in
a JavaScript object and having that object support multiple callbacks if it
wants
to.