W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [XHR2] ArrayBuffer integration

From: Michael Nordman <michaeln@google.com>
Date: Mon, 27 Sep 2010 18:22:13 -0700
Message-ID: <AANLkTimM9pEE3WrgXpx6BJfKDPQaYDXAtr8-xtH=dcSK@mail.gmail.com>
To: Web Applications Working Group WG <public-webapps@w3.org>
Cc: Jian Li <jianli@chromium.org>, Anne van Kesteren <annevk@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Chris Marrin <cmarrin@apple.com>, Kenneth Russell <kbr@google.com>, Vladimir Vukicevic <vladimir@mozilla.com>, Chris Rogers <crogers@google.com>
A couple of us have been looking at webkit's XHR impl and realized that to
support performant access to the response via responseArrayBuffer and
responseText would cause us to keep two copies of the data around, a raw
data buffer and the second decoded text buffer. Considering the overwhelming
number of responseText only use cases, it would be nice to not incur extra
costs to support a new binary accessor which would be rarely used compared
to the text accessor. So some way of making these mutually exclusive in the
API.

Should we have an asArrayBuffer attribute (or similar) to tell XHR up front
how the caller wishes to access the response?

Or maybe specify the accessors such that when you use responseText you can
not later access responseArrayBuffer and vice versa?

Are there any use cases where you'd need it both ways?

-Michael


On Fri, Sep 24, 2010 at 5:41 PM, Kenneth Russell <kbr@google.com> wrote:

> On Fri, Sep 24, 2010 at 5:36 PM, Jian Li <jianli@chromium.org> wrote:
> > I plan to add ArrayBuffer support to BlobBuilder and FileReader. Chris,
> it
> > is good that you would pick up the work for XHR. We can talk about how
> we're
> > going to add ArrayBufferView to read ArrayBuffer.
>
> All of the Typed Array view types (Uint8Array, Float32Array, etc.)
> except for Float64Array are already implemented in WebKit. The major
> missing one for file and network I/O is DataView.
>
> -Ken
>
> > Jian
> >
> > On Fri, Sep 24, 2010 at 5:23 PM, Kenneth Russell <kbr@google.com> wrote:
> >>
> >> On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren <annevk@opera.com>
> >> wrote:
> >> > On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell <kbr@google.com>
> >> > wrote:
> >> >>
> >> >> Mozilla's experimental name is "mozResponseArrayBuffer", so perhaps
> to
> >> >> avoid collisions the spec could call it responseArrayBuffer.
> >> >
> >> > While I do not think there would be collision (at least not in
> >> > ECMAScript,
> >> > which is what we are designing for) naming it responseArrayBuffer is
> >> > fine
> >> > with me. And also now done that way in the draft. Still need to get a
> >> > saner
> >> > reference to the ArrayBuffer specification than
> >> >
> >> >
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
> >> > though. :-)
> >> >
> >> > http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
> >>
> >> Thanks, this is great and very exciting. This motivates implementing
> >> the proposed DataView interface (
> >>
> >>
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6
> >> ), which will make it easier to read multi-byte values with specified
> >> endianness out of an ArrayBuffer. For WebKit I've filed
> >> https://bugs.webkit.org/show_bug.cgi?id=46541 .
> >>
> >> -Ken
> >>
> >> > (You can also do send(ArrayBuffer) obviously. I personally think
> >> > supporting
> >> > this for both BlobBuilder and send() makes sense. That way Blob/File
> >> > etc.
> >> > work too.)
> >> >
> >> >
> >> > --
> >> > Anne van Kesteren
> >> > http://annevankesteren.nl/
> >> >
> >>
> >
> >
>
>
Received on Tuesday, 28 September 2010 01:23:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT