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 <da...@davidflanagan.com
<mailto:da...@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
