Re: [File API] events vs callbacks

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);

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). Or simply using
XHR which indeed already works in the current draft, at least once the
filedata protocol is more defined.

/ Jonas

Received on Tuesday, 11 August 2009 17:52:34 UTC