W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: Alternative File API

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, 18 Aug 2009 11:46:22 -0700
Message-ID: <c9e12660908181146sea288acw8e71f35943a7a59a@mail.gmail.com>
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

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.

Received on Tuesday, 18 August 2009 18:47:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC