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

On 10/30/10 3:34 AM, Jonas Sicking wrote:
> I'm not entirely following what your concern is. I.e. what usage
> pattern you are worried will either break in existing code, or people
> will get wrong in new code.

Well, one simple usage pattern is using the jquery "get me some stuff" 
API and then trying to get something other than responseText or 
responseXML off the resulting XHR.

> Like maciej showed, if we expose multiple properties which at the same
> time contain the result data in different formats, it's very easy to
> accidentally use more memory than needed. For example by checking
> progress by measuring .responseText.length, or by checking what type
> was returned by poking at the various properties until finding one
> that works.

Fair.  That last problem I had not thought of.....

> I say by making it possible to choose if you want streaming or
> give-me-the-full-result-once-all-of-it-is-downloaded behavior. If need
> be before the request is started.

The problem is that it seems to be somewhat common for the request 
starter and the data consumer to be different entities (and for there to 
be more than one data consumer).

>> That seems like an implementation detail.  Nothing is really preventing
>> segmented storage of the data (not even the responseArrayBuffer getter, if
>> it were added).
>
> Indeed, though at some point the implementation likely will have to
> flatten the data in order to not have to support fragmented
> strings/arraybuffers throughout the JS engine.

Sure.

>> As long as only one entity is doing the expecting, right?  Right now jquery
>> expects to get responseText, so if you expect something else you can't use
>> jquery's XHR wrappers, say....
>
> I'm not terribly worried about library wrappers. My money is on
> libraries updating faster than browsers are releasing implementations.

My money is on jquery tip getting updated faster than browsers release 
implementations.

My money is on browsers releasing implementations way faster than 
websites are updated to a newer jquery version.

That, at least, has been our experience with libraries in the past... 
The last time jquery made a bogus assumption and then fixed it several 
months before a release of ours that would cause breakage due to that 
assumption it took heroic efforts over a course of many months by a 
whole team of people just to get the top several dozen sites being 
bitten by the bug to update.

> I've assumed that all proposals made so far maintain full backwards
> compatibility. So I'm not terribly worried about existing content. Old
> browsers will hold people back much more than old JS libraries.

I think you're being way too optimistic; see above.

-Boris

Received on Monday, 1 November 2010 20:40:31 UTC