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.hanc...@access-company.com -----Original Message----- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Wednesday, November 18, 2009 10:31 AM To: a...@mozilla.com; Marcin Hanclik Cc: WebApps WG; public-device-a...@w3.org Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan <a...@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.
