Re: Alternative File API

On Aug 19, 2009, at 1:28 PM, Arun Ranganathan wrote:

> Nikunj R. Mehta wrote:
>> Hi Arun,
>>
>> Thanks for pulling together all those references and sharing your  
>> research conclusions in such painstaking details. I really  
>> appreciate your hard work. I was particularly interested in seeing  
>> whether you had included the Java I/O API design in your work.  
>> Evidently, you did, but it had no influence on the result, as can  
>> be seen in the new proposal I have circulated.
> I wouldn't say it had no influence on the result :-)  I stated in my  
> email that the reason that the Java I/O model (FileStream) or for  
> that matter the Flash model (FileInputStream) are useful is that  
> *both* have primitives for bytes or byte arrays:
>
> For Flash, you have http://livedocs.adobe.com/flex/3/langref/flash/utils/ByteArray.html 
>  which you can use with FileInputStream
> For Java, you have http://java.sun.com/j2se/1.4.2/docs/api/java/io/FileInputStream.html#read%28byte 
> []%29 which reads the file content into a "buffer" which is a byte  
> array.  Incidentally, you also have this ability in Silverlight.
>

I think you can achieve similar results with composability without  
needing byte arrays. I am adding that to my proposal just now.

What I really miss in your draft is the lessons taught by Java File I/ 
O design.

> But, in order to use the model you have constructed, which is the  
> equivalent of the InputStream way of doing things, you have to  
> "simulate" this ability using an array of integers.  This is not  
> advisable!  Also, I disagree that you can compare this directly to  
> what Gears does with Blob, but I'd like to hear from Gears folks  
> (and more from me later).

Better to discuss this in the thread I created. Can you oblige?

>  I'm keen to see ECMAScript give us types for better manipulation of  
> binary data.  This is something that we've seen in some browser  
> implementations, and I'm keen to feed it into TC-39 (the ECMAScript  
> WG).  This would certainly change what we can use for file I/O, if  
> not the shape of the entire API.
>
> There are a few other things about your model which I'd like to  
> think about and respond to at greater length later when I have more  
> time, particularly the "concurrent file access" scenario.  I will  
> say I'm warming up to separate error handling more and more :-)  Of  
> course, I'm very interested in feedback from others about your model.

Nikunj
http://o-micron.blogspot.com

Received on Wednesday, 19 August 2009 22:21:09 UTC