[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] DataView suggestions



Thanks for the answer. 

I did not know the target goals of the API design. You should probably write in the specifications that you intend the API to be as small as possible. Hence, that a _javascript_ wrapper on-top of it is required to have the best user experience using it.

As for the string conversion, I can't promise anything. I am no expert at all on this subject.

--
Christopher CHEDEAU - Vjeux
EPITA - LRDE - Ing2 2012
Curse.com Web Developer

http://blog.vjeux.com/


On Tue, Apr 12, 2011 at 4:18 AM, Kenneth Russell <kbr@google.com> wrote:
Hi Christopher,

Thanks for your feedback.

Earlier versions of the DataView class were stateful, and contained a
cursor for stream-like input. Discussion on the WebGL mailing list
informed the current design. The basic idea is that a cursor can be
easily implemented in a wrapper library in pure _javascript_. It isn't
necessary for the DataView class to contain all of the functionality.
The simpler the DataView class, the more likely it is that the entry
points will be well optimized by the browser's _javascript_ engines,
which is important to get good file reading and writing performance.

More responses inline.

On Fri, Apr 8, 2011 at 3:52 AM, Christopher Chedeau - Vjeux
<vjeuxx@gmail.com> wrote:
> Hello,
> I have been working on a lib that provides DataView API for all the browsers
> (it uses the best feature available from String, Typed Array or DataView)
> called jDataView: https://github.com/vjeux/jsDataView/
> While working on this library, I found that the current API was not really
> practical to use. Adding those few points would make the handling of binary
> data more enjoyable.
>
> 1) Addition of littleEndian to the constructor
> A binary file is either in littleEndian or bigEndian form. It is therefore
> really annoying to have to define the endianness everytime you read a value.
> This is even more annoying since the default value is bigEndian whereas most
> files nowadays are in littleEndian.
> To solve this, we can add a parameter littleEndian to the DataView
> constructor. When you read/write and the littleEndian value is undefined,
> this is the value from the constructor that is being used. I would also set
> bigEndian by default.

I think that this sort of functionality belongs in a wrapper library.
There's no reason to artificially limit a particular DataView instance
to reading only big- or little-endian data. One could imagine a file
format that contained both big- and little-endian values, though it
would be convoluted.

> 2) File cursor
> Most of the time you read a file sequentially. With the current API, you
> have to keep a cursor of where you are at and this is extremely annoying.
> You would like to write
> var a = view.getInt8();
> var b = view.getFloat32();
> Instead you have to write
> var cursor = 0;
> var a = view.getInt8(cursor); cursor += 1;
> var b = view.getFloat32(cursor); cursor += 4;
> DataView could have an internal cursor initialized to 0 at creation. Every
> time you make a read/write, it would be set to the end of what has been
> read/written. byteOffset will be set to the cursor position. if undefined.
> In order to manipulate the cursor, we would have two functions:
> seek(byteOffset) and tell()

Per above, this was already considered and rejected. It can easily be
implemented in a wrapper library.

> 3) getChar and getString
> Often, binary files also contain characters and strings. With the current
> API, this is extremely annoying to read those types of values.
> I suggest to add 4 new functions:
> getChar(byteOffset)
> getString(length, byteOffset)
> setChar(byteOffset, char)
> setString(byteOffset, string, optional length)
> One issue I see is encoding. I believe that strings in binary files are
> often in ASCII while _javascript_ strings are UTF-8.

Better interoperability between the Typed Array API and _javascript_
strings is definitely needed, and there have been discussions on this
mailing list about how to achieve it. Unfortunately, so far there
hasn't been a champion of this functionality to specify it.

I am no expert in this area, but I have a feeling that the API needed
for this functionality will be moderately sized. It seems clear that
it will be necessary to support multiple character encodings. For
these reasons, I think the best path forward would be to add a
separate specification defining _javascript_ string encoding and
decoding into typed arrays and/or the DataView class. If you'd be
willing to contribute to this effort that would be great.

-Ken

> I hope that these suggestions will help to make the DataView API more user
> friendly. It is important to have a good support for binary files if we want
> to make browser _javascript_ future-proof! :)
>
> --
> Christopher CHEDEAU - Vjeux
> EPITA - LRDE - Ing2 2012
> Curse.com Web Developer
>
> http://blog.vjeux.com/
>