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
