- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Tue, 18 Aug 2009 11:46:22 -0700
- To: arun@mozilla.com
- Cc: Aaron Boodman <aa@google.com>, Olli Pettay <Olli.Pettay@helsinki.fi>, Michael Nordman <michaeln@google.com>, Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>
On Tue, Aug 18, 2009 at 11:04 AM, Arun Ranganathan<arun@mozilla.com> wrote: > Aaron Boodman wrote: >> >> 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. >> >> > > I agree that supporting progress feedback is useful, but think it is > optional and probably not as useful as "network activity" progress feedback. > I think it is possible to do so within the existing API, e.g. via another > (optional) callback. The benefit of doing this is that it provides a > potentially useful feature while sticking to the simplicity of the existing > model. The drawback is that it doesn't use the intended event model for the > web. This drawback is probably what's behind the "correctness" argument. Sounds like your making reference to someone's "corretness" argument, and then speculating on the reasoning behind that. You know, you could *ask*. And what "correctness" argument are you referring to? Is it this: | The two corners above would not conflict since each would | presumably be working with a distinct FileReader object. - ? That argument did not have anything to do about "the intended event model for the web". Whatever it is, maybe you should *ask* the person, rather than making assumptions about it. > Do you have strong opinions on *how* to support progress feedback? >> >> 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. What "file operation" and what "caller"? If people really want to broadcast events, they can do that >> manually. >> > > I strongly agree! > *What* don't you buy? The use-case that wasn't mentioned? Lets see an example of that is done. I think doing that will demonstrate the inherent complexity involved in that. Lets see an example of that is done. http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0317.html Garrett
Received on Tuesday, 18 August 2009 18:47:03 UTC