[FileReader API, ProgressEvents] Design patterns, FileWriter API

Hi,

This is a set of architectural comments to the FileReader API, ProgressEvents and the design patterns for DAP.

For DAP in [1] I propose the following consistency requirement (still [1] is a very early draft with bugs):
"All APIs MUST follow the same convention when handling callback functions (e.g. XHR / FileReaderAPI style with onreadystatechange, or ProgressEvents with EventTarget)."
There is currently discrepancy between XHR/FileReaderAPI and the ProgressEvents in terms of handling the same functionality differently.

The ProgressEvents specification proposes is the event firing order [2], that could be summarized as a firing grammar
(up to some lack of clarity around suspend and stalled events):

progressgrammar = loadstart working (error | abort | load) loadend
working         = *( progress | (progress suspend progress) | (progress stalled progress) )

In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly.
Specifically the event names are the same as within the ProgressEvents, but I assume they should be adjusted to the FileReader API.
Therefore instead of (forgetting the above issue with the callback model for now):

  attribute Function onloadstart;
  attribute Function onprogress;
  attribute Function onload;
  attribute Function onabort;
  attribute Function onerror;
  attribute Function onloadend;

we could have:

  attribute Function onreadstart;
  attribute Function onprogress;
  attribute Function onread;
  attribute Function onabort;
  attribute Function onerror;
  attribute Function onreadend;

Assuming that we will have an interface like FileWriter in the (near) future, we could already now anticipate that the interface would include e.g. the following:

  attribute Function onwritestart;
  attribute Function onprogress;
  attribute Function onwrite;
  attribute Function onabort;
  attribute Function onerror;
  attribute Function onwriteend;

Then, the ProgressEvents spec could act as a design pattern definition for lengthy, asynchronous operations.
To make it happen, the names of the events there could be changed to be generic:
loadstart -> start
progress
stalled
suspend
error
abort
load -> done
loadend -> end

Additionally the ProgressEvents spec could be divided (or split into two documents? ) to contain the section specific to the design pattern definition and to the section specific to data transfer / loading.

What to you think?

Thanks,
Marcin

[1] http://dev.w3.org/cvsweb/~checkout~/2009/dap/design-patterns/Overview.html?rev=1.1&content-type=text/html;%20charset=iso-8859-1
[2] http://dev.w3.org/2006/webapi/progress/Progress.html#Event1

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


________________________________________

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 Tuesday, 17 November 2009 10:12:35 UTC