: Thursday, November 19, 2009 12:55 AM
To: Marcin Hanclik
Cc: Anne van Kesteren; WebApps WG; public-device-a...@w3.org
Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Marcin Hanclik wrote:
Hi Anne,
XHR still is used also for data retrieval, so it is a kind of border
On Nov 19, 2009, at 11:35 , Marcin Hanclik wrote:
To be clear, IMHO it's absolutely too late for FileReader
FileReader is still ED, therefore we may have time, I think.
Actually, it's published (as a WD) and has a rather long background history of
previous development in the File Upload spec.
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
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
Marcin Hanclik wrote:
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.
On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com
wrote:
Greetings Marcin,
Thanks for the thoughtful feedback. My comments below:
In my opinion some part of the design from ProgressEvents is taken over
in FileReader API too directly.
Specifically the event names are
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
Greetings Marcin,
Thanks for the thoughtful feedback. My comments below:
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
