Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"
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
Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"
On 11/3/10 7:06 AM, Jonas Sicking wrote: No, my concern is that browsers will implement this, and then sites that haven't updated their jquery, and probably never plan to do it, will start using the new stuff browsers have implemented. But won't that always fail? If the author either sets .responseType when jquery doesn't expect it, or the author uses .response when jquery hasn't set .responseType? In the particular case of jquery, yes, unless there are some try/catch blocks around. With other things, it might not be so simple. Looking at http://prototypejs.org/assets/2009/8/31/prototype.js it seems they try/catch around their .responseText stuff and turn those exceptions it into events Yes, it means that pages that use old code can't use the new features together with that code, but I don't see that as a big problem in this case. My problem is that it seems, to me, to be really easy to get into situations where things _seem_ to work, but don't really, or don't with a slight change in totally unrelated code. Since jquery always gets responseText that's not the case there in that you'd get an exception at that point. But prototype is catching such exceptions, and again my concern is cases where different codepaths end up assuming different things from the same XHR in hard-to-debug ways. I might be wrong, of course. But I think we'd be creating a debugging nightmare for web page authors. -Boris
Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"
On 11/3/10 7:15 AM, Tab Atkins Jr. wrote: In this particular case, if someone is using jQuery to do their XHR, they will basically never touch the native XHR object. Why does jquery pass that object back in the response callback, then? -Boris
Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"
On Tue, Nov 2, 2010 at 9:16 PM, Boris Zbarsky wrote: > On 11/2/10 11:35 PM, Jonas Sicking wrote: >> >> So your concern is that jQuery will update to use the new API before >> browsers implement it. And then once browsers do implement it and >> start honoring the .responseType by making various existing properties >> throw, things will fail? > > No, my concern is that browsers will implement this, and then sites that > haven't updated their jquery, and probably never plan to do it, will start > using the new stuff browsers have implemented. In this particular case, if someone is using jQuery to do their XHR, they will basically never touch the native XHR object. Native XHR sucks pretty badly, which is why $.get, $.post, and generally $.ajax exist. So, there's little chance that authors will be trying to use the new features with old jQuery, because it's impossible without hacking down into the native object. ~TJ
Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"
On Wed, Nov 3, 2010 at 5:16 AM, Boris Zbarsky wrote: > On 11/2/10 11:35 PM, Jonas Sicking wrote: >> >> So your concern is that jQuery will update to use the new API before >> browsers implement it. And then once browsers do implement it and >> start honoring the .responseType by making various existing properties >> throw, things will fail? > > No, my concern is that browsers will implement this, and then sites that > haven't updated their jquery, and probably never plan to do it, will start > using the new stuff browsers have implemented. But won't that always fail? If the author either sets .responseType when jquery doesn't expect it, or the author uses .response when jquery hasn't set .responseType? Yes, it means that pages that use old code can't use the new features together with that code, but I don't see that as a big problem in this case. That's a problem that will go away much faster than problems in the XHR interface will. / Jonas
Notes from WebApps' 1 November 2010 "Gathering"
WebApps had an informal un-conference style gathering in Lyon on November 1. The "notes" from that gathering are available at the following and copied below: http://www.w3.org/2010/11/01-webapps-minutes.html -Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - WebApps F2F meeting 01 Nov 2010 See also: [2]IRC log [2] http://www.w3.org/2010/11/01-webapps-irc Attendees Present Adrian, Sam, Maciej, PLH, Bryan, DaveR, AnnB, AdamB, timeless, WonsukLee, Eliot, Bryan_Sullivan, chaals, Rishida, Aron, DanA, LarryM, Ashok, Aharon, Art_Barstow, Mike_Smith, Wonsuk_Lee, zhang_chengyan, wujing, junliao, Johnson_Wang, Adam_Boyet, Bo_Chen, Hiro_I, Yung_Yu_Chan, Doug_Schepers, Josh_Soref, Eric_Uhrane, Laszlo_Gombos, Yael_Aharon Regrets Chair ArtB Scribe dsr, timeless_mbp, chaals Contents * [3]Topics 1. [4]WebIDL and TC39 2. [5]Web Sockets 3. [6]Introductions 4. [7]Web Workers 5. [8]Programmable Cache 6. [9]Selectors API 7. [10]XBL2 8. [11]Clipboard 9. [12]WebSQL 10. [13]XHR + Widgets 11. [14]Web Events 12. [15]CORS and UMP 13. [16]i18n 14. [17]DOM 3 Events Input Locale * [18]Summary of Action Items _ ScribeNick: ArtB Date: 1 November 2010 WebIDL and TC39 Adrian: part of the next TC39 meeting (in ~2week) will include discussions with some people in WebApps ... there is a perception that the other group is not interested in working together ... for example TC39 people seem to think W3C people is not interested in working with them ... and within WebApps, there seems to some disinterest in working with TC39 ... there are some tactical issues in the WebIDL spec that need to be resolved ... see f.ex. public-script-coord ... Need to talk about how to work together at a Strategic level ... We need to prioritize the work in both groups ... so there is better coordination ... For instance adding features need to be discussed ... The 2 groups have different timelines and there is a gap there that needs to be filled ... WebIDL is the key spec that has interest from both sides ... Microsoft people in TC39 have some issues with the structure of WebIDL spec ... Some parts of WebIDL may want to be deprecated ... f.ex. we don't want some old patterns continued ... Think we are talking passed each other a bit ... PLH has been involved in conversations with TC39 Chair PLH: when I asked 6 mos ago if any WG wants to meet with TC39, no one responded ... Cam will be at TC39 meeting in two weeks ... Are there any other specs TC39 cares about? Adrian: WebIDl is certainly the key spec ... but there are some other specs wait what, there's a WebApps WG meeting after all? Adrian: The TC heard there were no other specs ... I don't think there is fault or blame here ... I just think there is a need for closer collaboration mjs, k thanks Adrian: Think there should be a more formal relationship ... We all have the responsibility to raise the issues ... As ES5 progresses, and more and more APIs @ W3C are written, I think there will be more collaboration that will be needed ... We must make sure ES and W3C APIs work well together ... Don't want a bunch of ad hoc APIS ... as that may create some interop probs ... Not sure how we fix the perception that neither group is interested in working with the other Maciej: one thing we can do is to have some coord calls ... can also have someone participate in both groups ... and make sure they are talking to both groups ... There can be issues where two people from the same company may disagree PLH: so far, WebIDL is the key spec ... Good news there is that Cam is back and he will be attending TC39 meeting at Apple in 2 weeks ... We do meet every couple of months with IETF with a specific agenda ... But if there is a need to talk about a specific issue, then that's different Adrian: the joint meeting is in a couple of weeks PLH: do we need to send a W3C staff member to the TC39 meeting? Adrian: no, I don't think that is necessary ... but I think the meeting should include a discussion about liaisions and next steps PLH: I can attend remotely ... will their be a phone? Maciej: yes, I think that can be arranged AB: that sounds like a good first step ... Is Chaals attending ... has WebApps been invited to the meeting? Adrian: yes, I think WebApps was invited to the coordination part of the meeting PLH: I will send e-mail John re the Nov meeting Adrian: Maciej forwarded a related email to the list on Oct 11
