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

Re: Alternative File API

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 17 Aug 2009 07:07:48 -0700
Message-ID: <4A896434.9010306@mozilla.com>
To: Michael Nordman <michaeln@google.com>
CC: Jonas Sicking <jonas@sicking.cc>, Garrett Smith <dhtmlkitchen@gmail.com>, Webapps WG <public-webapps@w3.org>
Michael Nordman wrote:
> Currently we have File and FileData, where a File object ISA FileData
> object... completion is delivered via readXXX method completion callbacks.
> It would be easy to add progress callbacks to those readXXX methods.
> I think Garrets point about two different corners of the webapp issuing
> reads against a File/FileData at the same time really only becomes an issue
> when one of those two corners decides to cancelReads() on the File/FileData
> instance.
>
> 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. Your code snippets
> demonstrate that it takes more busy work to use... but setting the event
> handlers has to happen somewhere.
>
> If we go with distinct 'Readers', maybe have the 'Data' object responsible
> for manufacturing them as there could be differences in where the 'Data'
> really resides and what it takes to retrieve it.
>
> var reader = data.createReader();
>
> File - represents a file in the file system
> BinaryData - represents a bag of binary bits (roughly analogous to a
> Gears.Blob)
> BinaryDataReader - an interface to read those bits
>
> File isa BinaryData
> XHR.ResponseBody isa BinaryData
> SQLBlob isa BinaryData
>
>   

I'm willing to change the specification to support Events and Readers, 
though I don't necessarily think it is "more JavaScripty."  I continue 
to be concerned that we've made the model a bit more complex, but it 
certainly is more powerful.  Progress Events seems to be the main use 
case, and it seems our model has stretched to most elegantly accommodate 
it.  So Data or BinaryData would no longer have accessors, but probably 
have slice( ), size, etc.  Using the same 'isa' shorthand (which I 
gather you're using from word grammar):

Data -- represents raw data, has slice( ), has size
File isa Data (File has mediaType, has url)
DataReader isa EventTarget

-- A*
Received on Monday, 17 August 2009 14:08:34 GMT

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