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
*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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT