W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2009

Re: Binary data (ByteArray/ByteVector) proposal on public-script-coord

From: Breton Slivka <zen@zenpsycho.com>
Date: Sat, 7 Nov 2009 01:31:50 +1100
Message-ID: <ae2b2ba80911060631x30e2056g55ed978bdfee30ea@mail.gmail.com>
To: P T Withington <ptw@pobox.com>
Cc: Maciej Stachowiak <mjs@apple.com>, public-script-coord@w3.org, es-discuss Steen <es-discuss@mozilla.org>
On Sat, Nov 7, 2009 at 12:43 AM, P T Withington <ptw@pobox.com> wrote:
> On 2009-11-05, at 19:42, Maciej Stachowiak wrote:
>
>> My claim is that Data is not much like these things. I believe it is more
>> like String. It happens to be a sequence (of a very specific type), but it's
>> specialized enough to be worth treating differently. Do people often regret
>> that String is not an Array?
>
> Data is like an 8-bit "null encoded" String.  Which makes me wonder if you
> really just want to extend String to allow different encodings.  But I also
> regret String not being and Array.  Others must have too, because at one
> point I'm sure there was a proposal to make [] on string mean charAt?

Sorry to get philisophical here, but data is anything you happen to
interpret it as, it's not any particular thing. It could be an image,
it could be a string, it could be machine instructions, it could be a
sequence of octets, it could be hexidecimal. Asking what data is like
is a little bit useless. The question to ask is what kind of api makes
the most sense for conveniently manipulating data on a low level, and
in a way that isn't unfeasably slow, or awkward. What kind of api will
allow the programmer to efficiently interpret that data as things
other than what are built into the browser. I think the C language has
possibly biased us into thinking of data as a sequence of 8-bit bytes,
when that is just what happened to be convenient for C. There are
other ways to think about data: even within C you can define a struct,
point it at some area of memory, and the struct magically interprets
that data as an object like thing. Or you can even scanf. These
concepts do not depend on a byte stream, or "string" interpretation of
data.


By the way, it might not be standard, but "hello world"[0] returns "h"
on anything but IE, so far as I've tried.

My question is (since nobody seems to have brought it up yet) is how
does this proposal fit into the html5 canvas data api? (not the data
URI api).

If you call canvascontext.getImageData(0,0,width,height), you get an
object with some mutable properties, and a data property holding what
looks like an array of numbers between 0 and 255. The data property
supposedly has an efficient implementation. There is also a
putImageData function which accepts a data object, but not an array
object, and a constructor, context.createImageData(width,height);

This is already in browsers, and is in the process of being
standardised in html5. I just wonder what happens if ecmascript then
adds its own data object, how would it interact with the canvas data
apis?
Received on Friday, 6 November 2009 18:52:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC