Re: Alternative File API

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 
which you can use with FileInputStream
For Java, you have[]%29 
which reads the file content into a "buffer" which is a byte array.  
Incidentally, you also have this ability in Silverlight.

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).  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.

-- A*

Received on Wednesday, 19 August 2009 20:28:54 UTC