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: Mon, 10 Aug 2009 17:47:29 -0700
Message-ID: <63df84f0908101747j53dc3919ga03e953056ae7757@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 Sat, Aug 8, 2009 at 6:42 AM, Olli Pettay<Olli.Pettay@helsinki.fi> wrote:
> 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();

I'm fairly strongly against the idea of using the File object (or
FileData object) as both the object representing a file, and as the
object that represents a read-request from a file.

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.

It would mean that if you ever plan on reading from a File, you have
to be very careful never to pass that File to anyone. If you do, you
then have to slice the file before you read from it.

This is very error prone in that it's not at all obvious that you need
to do this, and things generally look like they should work even if
you simply use the File object directly.

/ Jonas
Received on Tuesday, 11 August 2009 00:48:30 GMT

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