On 8/6/09 9:31 PM, Jonas Sicking wrote:
On Wed, Aug 5, 2009 at 4:26 AM, Anne van Kesteren<ann...@opera.com> wrote:
On Wed, 05 Aug 2009 10:04:28 +0200, Arun Ranganathan<a...@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
