- From: Aaron Boodman <aa@google.com>
- Date: Mon, 17 Aug 2009 23:42:04 -0700
- To: Olli Pettay <Olli.Pettay@helsinki.fi>
- Cc: Michael Nordman <michaeln@google.com>, Jonas Sicking <jonas@sicking.cc>, Garrett Smith <dhtmlkitchen@gmail.com>, Webapps WG <public-webapps@w3.org>
On Mon, Aug 17, 2009 at 2:45 AM, Olli Pettay<Olli.Pettay@helsinki.fi> wrote: > On 8/17/09 12:33 AM, Michael Nordman wrote: >> >> Strictly speaking, I think the seperate 'Reader' class makes for a more >> correct API. The two corners above would not conflict since each would >> presumably be working with a distinct FileReader object. And the >> seperate 'Reader' with event handlers seems more javscript'y. > > I agree with this. Reader+events 'feels' pretty much what I'd like to see. I don't think javascriptyness is a good attribute to argue about. In a group this large, with different backgrounds, this just comes down to preference. I don't personally care for a separate Reader object or events, and don't feel like such is javascripty. But <meh>. The truth is the web platform is inconsistent already. Having this go one way or the other is not going to ruin it. Best to argue for what the goals should be, then for what solves them, objectively. There seems to be two points of argument: a) Whether it is worth supporting progress events b) Whether the platform should directly support multiple listeners on a single file read operation For a), as much as I dislike it stylistically, I think that in this case we should err on the side of power. If the raw API does not support progress events, they will be impossible to implement. If the raw API does support progress events, people can ignore them if they want. For b), I don't buy that it is valuable to support this directly. In the vast majority of cases, a file operation is something with one caller. If people really want to broadcast events, they can do that manually. - a
Received on Tuesday, 18 August 2009 06:42:43 UTC