Re: [File API] events vs callbacks

On Tue, Aug 11, 2009 at 12:16 PM, Olli Pettay<Olli.Pettay@helsinki.fi> wrote:
> On 8/11/09 8:51 PM, Jonas Sicking wrote:
>>
>> On Tue, Aug 11, 2009 at 1:56 AM, Olli Pettay<Olli.Pettay@helsinki.fi>
>>  wrote:
>>>
>>> On 8/11/09 3:47 AM, Jonas Sicking wrote:
>>>>
>>>> Today if you use XMLHttpRequest, you never have to worry if someone
>>>> else happen to be reading from the same URI as you, if we go with the
>>>> above API the same basically wouldn't be true for files.
>>>
>>> Yes you do need to worry with XHR. If I call open/send, it will cancel
>>> the
>>> current request.
>>>
>>> To me supporting progress events sounds more important than
>>> having easy way to do concurrent reads using the same FileData.
>>> (And even with events, concurrent reads are very simple, just not
>>> using the same FileData)
>>
>> The main problem isn't supporting multiple parallel reads, but rather
>> that if someone does attempt to do multiple reads from the same file,
>> it's very likely to result in buggy pages. I.e. we can put "Don't read
>> from the same File instance multiple times in parallel", but that's
>> unlikely to actually affect anyone.
>>
>> I'd also say that multiple reads is a use case that we do want to
>> support given how big of a hassle it is to read from multiple places
>> in a large file consecutively. Compare
>>
>> file.getAsBinary(handler1, 0, 1024);
>> file.getAsBinary(handler2, 4096, 5120);
>> file.getAsBinary(handler3, 1048576, 1049600);
>>
>> to
>>
>> file.getAsBinary(function(...) {
>>   handler1(...);
>>   file.getAsBinary(function(...) {
>>     handler2(...);
>>     file.getAsBinary(handler3, 1048576, 1049600);
>>   }, 4096, 5120)
>> }, 0, 1024);
>
> You don't need to do that if you use slice:
>
> var part1 = file.slice(0, 1024);
> part1.onread = handler1;
> part1.getAsBinary();
> var part2 = file.slice(4096, 5120);
> part2 = handler2;
> part2.getAsBinary();
> var part3 = file.slice(1048576, 1049600);
> part3.onread = handler3;
> part3.getAsBinary();
>
> I know, this is longer than using the callback approach, but this is need
> only if someone really needs multiple simultaneous reads.
>
>> Also note that there are other solutions to supporing progress events,
>> such as the one suggested by Garrett with an external read object
>> (which would be pretty similar to how XHR does it).
> FileData can be seen as a "Reader" object.

My concern isn't that there are ways of using it correctly, my concern
is that it's very easy to use incorrectly with bugs as a result. This
concern exists as long as the read API is available on the File object
itself. We could make File not inherit FileData, but that wasn't the
proposal made so far.

Also note that progress events don't contain the actual data. So so
far no-one has made a proposal what allows for streaming, which I
would have thought would be an integral part of progress events.

I'll try to sketch up what I think would be a workable solution,
though I'm still unconvinced that it's a better one.

>> Or simply using
>> XHR which indeed already works in the current draft, at least once the
>> filedata protocol is more defined.
> What you mean with this? How would you load partial files and get progress
> events?

xhr.open("GET", myFile.slice(x, y).fileDataURI);
xhr.send();

/ Jonas

Received on Tuesday, 11 August 2009 20:58:52 UTC