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