[webkit-dev] XHR responseArrayBuffer attribute: possible implementation

[Darin Fisher]

The solution for .responseBlob was to add an .asBlob attribute that would
need to be set to true before calling .send().  We could do the same for
.responseArrayBuffer.

-Darin


On Mon, Oct 25, 2010 at 12:17 PM, Geoffrey Garen <ggaren at apple.com> wrote:

> Hi Chris.
>
> I like the efficiency of this approach. And I agree with your premise that
> a developer will probably only want one type of data (raw, text, or XML) per
> request, and not more than one.
>
> My biggest concern with this idea is that there's nothing obvious about the
> API pattern of three properties -- .responseText, .responseXML, and
> .responseArrayBuffer -- that makes clear that accessing one should prohibit
> access to the others. I wonder if there's a good way to make this clearer.
>
> Maybe the API should require the programmer to specify in advance what type
> of data he/she will ask for. For example, an extra responeType parameter
> passed to open. The default behavior would be the values currently
> supported, but you could opt into something specific for extra
> safety/performance, and new types of data:
>
> request.open("GET", "data.xml", true, "Text");
> request.open("GET", "data.xml", true, "XML");
> request.open("GET", "data.xml", true, "Bytes");
>
> Geoff
>
>
>
> On Oct 22, 2010, at 4:47 PM, Chris Rogers wrote:
>
> A few weeks ago I brought up the idea of implementing the
> responseArrayBuffer attribute for XHR:
>
> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-attribute
>
> One of the concerns was that it might require double the memory usage since
> the raw bytes would have to be accumulated along with the decoded text as
> it's being built up.  One possible solution which I've been discussing with
> James Robinson and Ken Russell is to defer decoding the text, and instead
> buffer the raw data as it comes in.  If there's any access to responseText
> (or responseXML), then the buffered data can be decoded into text at that
> time, and the buffered raw data discarded.  If that case happens, then from
> that point on no raw data buffering would happen and the text would be
> accumulated as it is right now.  Otherwise, if responseText is never
> accessed then the raw data continues to buffer until it's completely loaded.
>  Then an access to responseArrayBuffer can easily convert the raw bytes to
> an ArrayBuffer.
>
> The idea is that once responseText or responseXML is accessed, then it
> would no longer be possible to access responseArrayBuffer (an exception
> would be thrown).
> Conversely, once responseArrayBuffer is accessed, then it would no longer
> be possible to use responseText or responseXML (an exception would be
> thrown).
> This approach does seem a little strange because of the mutually exclusive
> nature of the access.  However, it seems that it would be hard to come up
> for a reasonable use case where both the raw bytes *and* the text would be
> needed for the same XHR.
>
> How does this sound as an approach?
>
> Chris
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101025/cdf42b13/attachment.html>