W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [File API] events vs callbacks

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 11 Aug 2009 18:11:31 -0700
Message-ID: <63df84f0908111811g18f53a9l50ff8831a36cb893@mail.gmail.com>
To: Olli Pettay <Olli.Pettay@helsinki.fi>
Cc: Anne van Kesteren <annevk@opera.com>, arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Aug 11, 2009 at 2:25 PM, Olli Pettay<Olli.Pettay@helsinki.fi> 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?

That just changes things so that instead of getting unexpected events,
you'll get an unexpected exception when calling .readX. That doesn't
seem to improve things.

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

Could be hard given that progress events might be used for many types
of data. Possibly the events can be subclassed, or implement multiple

/ Jonas
Received on Wednesday, 12 August 2009 01:12:32 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC