Re: Alternative File API

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.  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. If people really want to broadcast events, they can do that
> manually.
>   
I strongly agree!

-- A*

Received on Tuesday, 18 August 2009 18:04:49 UTC