Re: [File API] events vs callbacks

On Tue, Aug 11, 2009 at 2:25 PM, Olli Pettay<> wrote:
> On 8/11/09 11:57 PM, Jonas Sicking wrote:
>> 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.
> How? Especially if we prevent more than one read at time. How is the
> situation any worse than with XHR?

As stated, anyone can request a resource via XHR at anytime. Old CGI
progs were single threaded, but modern programs are multi-threaded
(e.g. Servlet), there is no prerequisite to ask the server if a file
read is OK first. Caller makes an XHR and it either succeeds or
doesn't. XHR doesn't require expectation on the caller; what state is
the file in.

Besides a file shouldn't be having behavior (read, write, delete).
Insted it hould be just having some properties like "name" or "size".
A good reason for having a separate object for read().

More in mail to Jonas,. I'm not done with that mail yet.


>> 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.
> Indeed. Progress events should be probably extended to contain data.
> (Progress Events Level 2?)
> -Olli

Received on Tuesday, 11 August 2009 23:18:50 UTC