Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

On 11/09/2010 11:54 AM, Chris Rogers wrote:
> Hi David,
>
> Sorry for the delayed response.

No problem. public-webapps got strangely quiet after I sent my last 
message, and I realized that everyone was off actually meeting about 
this stuff...

I think the idea of BinaryHttpRequest
> is a reasonable one.  As you point out, it simply side-steps any
> potential performance and compatibility issues.  Are you imagining that
> the API is effectively the same as XMLHttpRequest, except without the
> text and XML part?

Yes, roughly.  Thinking about it now, maybe just calling the new API 
HttpRequest would be better than BinaryHttpRequest.  It would support 
text, array buffers and blobs, but only one per request, selected via 
responseType and stored in a single response property.

It might be nice to modify the open() method so that you could specify 
the response type as the 3rd argument. (If that argument was present, 
the boolean async flag would become the fourth argument...)

You'd have to decide whether to continue to support readystatechange 
events or make a clean break from them with the new API.

I've never understood the need for AnonXMLHttpRequest, so I don't know 
if a new Anon constructor would be required or if anonymity could be 
handled via a constructor argument or property.

 From a specification standpoint, you have to decide whether to just 
leave XHR as a legacy API at level 1 and then define something new in 
the Level 2 specification. This would presumably be a pretty easy change 
to the existing Level 2 draft.  Or are we asking Anne to keep all the 
current XHR2 stuff and also add an HttpRequest object to support binary 
requests? That seems like a lot more work from a specification editing 
perspective.

	David

> How do other people feel about David's proposal?
>
> Chris
>
>
>
> On Wed, Nov 3, 2010 at 10:47 AM, David Flanagan <david@davidflanagan.com
> <mailto:david@davidflanagan.com>> wrote:
>
>     On 11/02/2010 07:06 PM, Boris Zbarsky wrote:
>
>         On 11/2/10 4:04 PM, David Flanagan wrote:
>
>             Boris (Mozilla) worries that creating a new mode in which
>             responseText
>             is unavailable will break jQuery applications.
>
>
>         And various others where the consumer of the data and the XHR
>         creator
>         are not the same entity. jQuery is just an obvious example that
>         we all
>         know about, is public, and clearly illustrates the pattern....
>
>             It occurs to me now, however, that the way to avoid breaking
>             jQuery is
>             to make responseType a constructor argument instead of a
>             property to be
>             set before send(). If I recall correctly, jQuery always
>             creates its own
>             XHR object, so if responseType is only settable at creation
>             time, then
>             the situation Boris fears won't arise. At least not with
>             that library.
>
>
>         That last sentence is key there... ;)
>
>         -Boris
>
>     So if making responseType a constructor argument isn't enough to
>     rescue the XHR API, that brings me back to my preferred solution: a
>     new BinaryHttpRequest API.
>
>     I think everyone on this thread has agreed that ease of use for web
>     developers is more important than ease for implementors.
>
>     As someone who documents stuff like this for web developers, I think
>     I've got a pretty good handle on what is easy to use and what is not
>     (documentation ease maps well to coding ease).
>
>     So in my professional capacity I argue that having a separate new
>     BinaryHttpRequest API would be conceptually simpler and easier for
>     developers than having a single XMLHttpRequest object with both a
>     legacy responseText property and a new response property and with
>     properties like responseType or asBlob that put the object into
>     special modes.
>
>     It would also be easier to document a new binary API than it would
>     be to document the optimization hints for the current API: "be
>     careful to not access both responseText and responseArrayBuffer
>     because that may cause extra memory usage, although on some
>     implementations that extra memory is going to be allocated no matter
>     what you do".
>
>        David
>
>

Received on Tuesday, 9 November 2010 20:58:10 UTC