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

Re: [File API] events vs callbacks

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Sat, 08 Aug 2009 16:42:47 +0300
Message-ID: <4A7D80D7.3000202@helsinki.fi>
To: Jonas Sicking <jonas@sicking.cc>
CC: Anne van Kesteren <annevk@opera.com>, arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
On 8/6/09 9:31 PM, Jonas Sicking wrote:
> On Wed, Aug 5, 2009 at 4:26 AM, Anne van Kesteren<annevk@opera.com>  wrote:
>> On Wed, 05 Aug 2009 10:04:28 +0200, Arun Ranganathan<arun@mozilla.com>
>> wrote:
>>>
>>> In the case of file read APIs, simply getting the data asynchronously is
>>> more convenient than using events.  There is no intrigue at work here,
>>> merely disagreement.
>>
>> I could imagine that for reading data you might want to have events though
>> so that in the future we can introduce progress events if that is found
>> necessary. E.g. if the actual file is not on the same computer as where the
>> user selected it.
>
> Do you have a proposal for what this would look like? I'm not excited
> about creating something that's significantly more complex than the
> current API.
>
> / Jonas
>

Using events doesn't have to be more complex than using async callbacks, 
and if we use events, it would be pretty natural to add
support for progress events at some point. (I do think we want progress
events, non-local-file-systems can be slow.)

The event could perhaps look something like
interface DataEvent : Event
{
   const unsigned short DATAURL = 1;
   const unsigned short TEXT    = 2;
   const unsigned short BINARY  = 3;
   const unsigned short BASE64  = 4;
   const unsigned short URL     = 5;

   readonly attribute unsigned short type;
   readonly attribute DOMString encoding; // or null
   readonly attribute DOMString data;
   void initDataEvent(in DOMString type,
                      in boolean canBubble,
                      in boolean cancelable,
                      in unsigned short type,
                      in DOMString encoding,
                      in DOMString data)
};

Then one could add the listener either using normal .addEventListener or 
use .onread property. There should be also .onerror property.

If one needs multiple simultaneous reads, I'd suggest
cloning FileData using (to-be-synchronous) splice/slice.
Perhaps we shouldn't even allow more than one concurrent read per FileData.

So if events are used,
myFile.getAsText(dataReader);
would become
myFile.onread = dataReader;
myFile.getAsText();


-Olli
Received on Saturday, 8 August 2009 13:43:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT