RE: [FileReader API, ProgressEvents] Design patterns, FileWriter API

Hi Anne,

XHR still is used also for data retrieval, so it is a kind of border case and I can live with "load" there :) .

Using "load" for writing to a file will mean that we are stuck with the legacy stuff. "load" and "write" pull semantically in the opposite directions, IMHO.

I think there is still time to change it in case of FileReader and prepare background for FileWriter.
I like the ProgressEvents spec and would keep it generic, i.e. change the names there to be generic and mandate their change in each spec that refer to ProgressEvents. PE is perfect to be a design pattern for asynchronous (and lengthy, more-than-one-shot, with-start-and-end, abortable and potentially erroneous) DAP APIs.

In the firing grammar:
progressgrammar = loadstart working (error | abort | load) loadend
working         = *( progress | (progress suspend progress) | (progress stalled progress) )

potentially rewritten to

progressgrammar = start working (error | abort | done) end
working         = *( progress | (progress suspend progress) | (progress stalled progress) )

we would only need to change the "working" rule to accommodate various event firing scenarios. Thus under the same design pattern we could accommodate XHR, HTML5's media API, FileReader and any new DAP API.
The event names could be related to the API for naming consistency, but firing model would be pre-defined were possible for design consistency.

For example for "directory walker" (aka File Directory API or File API Level 3: Directories as proposed by Robin) we could have:

directorywalkereventgrammar = start working (error | abort | done) end
working         = *( enterdir *file leavedir )

to be able to walk over e.g. 1M file entries in some FS.

Any thoughts?
I guess it may be over-engineering, but ...

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Anne van Kesteren [mailto:annevk@opera.com]
Sent: Wednesday, November 18, 2009 10:31 AM
To: arun@mozilla.com; Marcin Hanclik
Cc: WebApps WG; public-device-apis@w3.org
Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API

On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan <arun@mozilla.com>
wrote:
> I think that just as the names 'load*' were chosen for generic data
> transfer events (either networked or within a document), and are used
> within documents loaded in the DOM, XHR, and FileReader, we'll need
> reusable 'write*' events.  Without bikeshedding too much, I like your
> proposal above, but wonder whether we should use the name 'write*' or
> something else.  Since we already have document.write, 'write' is
> probably the most vetted string to use here :)

For what it's worth, for XMLHttpRequest "sending" events (which are
arguably somewhat like write) we still use loadstart/... and simply
dispatch them on a distinct object. I've no idea what the file writer API
will look like, but I can imagine we might be able to do the same there.


--
Anne van Kesteren
http://annevankesteren.nl/


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Wednesday, 18 November 2009 12:57:46 UTC