Re: File API Feedback

On Wed, Jul 8, 2009 at 5:05 PM, Jonas Sicking<jonas@sicking.cc> wrote:
> On Wed, Jul 8, 2009 at 2:26 PM, Garrett Smith<dhtmlkitchen@gmail.com> wrote:
>> On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sicking<jonas@sicking.cc> wrote:
>>> On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smith<dhtmlkitchen@gmail.com> wrote:
>>>> On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sicking<jonas@sicking.cc> wrote:
>>>>> 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?
>>>>
>>>> Why would someone want to attach more than one "click" handler to
>>>> document? It doesn't really matter why, but it is not hard to imagine
>>>> situations.
>>>>
>>>> For example, a notification for all success reads of files to notify
>>>> the user of "done", but then specific notifications about the current
>>>> file read. Not hard to imagine, but, AISB, it is not necessary to
>>>> consider all possible contexts. You have snipped and ignored that and
>>>> all other questions. Please don't do that.
>>>>
>>>> AISB, "An asynchronous file read is like an asynchronous XHR, in a
>>>> way." It can be desirable to want to have more than one callback for
>>>> XHR.
>>>
>>> I don't know that I've ever seen someone attach more than one
>>> eventhandler to an XHR request. In fact, I'm not even sure that IE
>>> supports more than one. For the longest time firefox didn't, and I
>>> don't think I ever saw a request for attaching more than one.
>>>
>>
>> Multiple callbacks for XHR are facilitated by custom events. That was
>> explained in the "<ajax library aside>" that I wrote.
>
> Sorry, I did not understand how the ajax library aside related to the
> original discussion. Reading it again I still don't understand the use
> case. I see that you are complaining about the API that the YUI
> library has, but I still don't see an explanation of a use case where
> you are reading data from a source and wish to have multiple unrelated
> listeners notified when that data is read. The way I am reading it you
> are saying that you have had this need in the past and that the YUI
> library didn't provide that functionality and thus was hard to work
> with. Can you explain the situation you were in when you had this
> need?
>

OK.

<simplification>
Two selects on search pane. First select triggers XHR. Regarding that:

Busy indicator:
 - listens for call being placed and shows UI busy indicator.
 - listens to "complete" and hides UI indicator.

StubManager listens to success from first.
</simplification>

The YUI connection manager, in all its gory, did not allow for such
clean/sane design. Sadly, the implementation above became a mere
fantasy. Using YUI was somewhat of a constraint (an unqualified
individual making technical decisions). Thus, callbacks became
coupled, called from asyncRequest's "callback" parameter (object)
which has "success" and "failure" properties. In that regard YUI
ConnectionManager has a leg-up on the FileUpload design because the
"callback" object is extensible. That is, "callback" can be given more
properties without changing the method signature to "asyncRequest".

FileUpload is less extensible. Adding configurable behavior would
either require get* methods to accept yet another parameter variable
or the addition of new properties on File.

file.getDataAtRange(4711, 5735, showFrameHandler, genericError);

Could be refactored to:-

file.getDataAtRange(4711, 5735, callbacksObject);

But that has problems as well.

So we're back to DOM Events.

You sound as if you have never been in a position where two objects
wanted to get an event notification. Procedural style of coding, e.g.
when A happens, do B, then do C. As opposed to, B listens to A, C
listens to A.

>>> Similarly, any API for file access that I have ever seen has only used
>>> a single callback. And file system APIs have existed for many many
>>> years.
>>>
>>> UI handling is a lot different from file handling so I don't think the
>>> analogy with the "click" event is that strong. The only similarity is
>>> the use of a callback.
>>
>> The user interacts with the file upload mechanism inside the browser. See?
>
> The user does not interact with the file read API in question here.
> The callbacks passed to getAsText/getAsDataURL are called in response
> to those calls, not in response to any user interaction.
>
>>> So again, can you give an example of where you'd like two listeners
>>> notified with data read from the file?
>>
>> What was wrong with the first time I posted it?
>>
>> Scroll back up and read:
>> | For example, a notification for all success reads of files to notify...
>>
>> Read the entire paragraph. Think, write, revise, etc.
>
> I did simply not understand your use case before. I still do not as
> described above.
>

Explained here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-August/012435.html

Another case is a page with two selects.

When user select an item from first SELECT, an indicator is displayed.
After a brief delay, the indicator goes away. The second SELECT gets
populated if the transaction was successful. Other parts of the form
change if the transaction was successful.

The Requirements section of the draft briefly describes some very
sophisticated applications:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.xhtml#requirements

Messaging and events would be indispensable there.

| #1) Example: A lyrics viewer. User wants to read song
| lyrics from songs in his plist file.  User browses for
| plist file.  File is opened, read, parsed, and presented
| to the user as a sortable, actionable list within a web
| application.  User can select songs to fetch lyrics.  User
| uses the "browse for file" dialog.

When the file reader starts, a message is displayed, e.g. the table
caption displays "loading: " + file.name.

When the file reader completes, the message changes.

The Results Table listens for success on the file read, as it receives
data, display the results of the songs found in the plist file.

Concurrently, a Lyrics Finder makes XHR to get lyrics data from the
plist file (which probably has more songs than can be be displayed on
the page).

The Results Table concurrently listens for success/progress
notifications from the remote call (XHR) to update the UI, displaying
indication of lyrics for a song being loaded (the "lyrics present"
indicator).

The Calendar application might likely be more complicated. Complexity
is best addressed by creating objects that have isolated
responsibility and that listen for messages of other components,
including read events from the file reader.

[snip discussion about timeout]

[snip Reader proposal explanation]

>> That proposal may have some problems. The role of a File originally
>> included behavior to read itself. I changed that to give the file a
>> "reader" property. From a role perspective, that's still a bit off.
>> Why should a file "have" a reader? Why cannot a Reader exist on its
>> own? That way, it can be passed a File to read, and some other
>> arguments.
>>
>> Example:
>>
>>  reader.read( file );
>>
>> and for ranges:-
>>
>>  reader.read( file[, start, end);
>>
>> Your question:-
>> "How would you do that using the API you are proposing?"
>>
>> Use an event handler on the Reader. For example:-
>> if(typeof FileReader != "undefined" && "BINARY" in FileReader) {
>>  reader = FileReader.create( FileReader.BINARY );
>>  if(reader != null) { // Reader was created.
>>    reader.addEventListener("success", func, false);
>>    reader.read(file, i, j);
>>  }
>> }
>>
>> Wrinkly, maybe but the gist.
>
> I understand. I would say that I think the API in the current proposal
> is better due to its simplicity.
>

Simplicity is a good reason for using events.

Having a separate event interface keeps the File interface simpler and
allows the individual callbacks to be simpler.

By not using events, everything gets more complicated.

[snip about snips]

>> Regards,
>>
>> Garrett
>
> / Jonas
>

Regards,

Garrett

Received on Thursday, 23 July 2009 04:38:15 UTC