Eric, anyone can come up with a solution. But if we strictly talking about jQuery and using it in an optimized, reliable, maximum support possible, then no.
I think the patch I illustrated resolves the issues. Overall, my thoughts are: 1) Not defining the readystatechange, the protocol is run synchronously. You put more pressure on the user agent by doing this. Which is fine, if the developers wants to do that, but jQuery is forcing XmlHttpRequestion() synchronous operations always, 2) The capture of states in indeterminate. With jQuery's implementation, it is erronounsly emulation a call back with the timer, but "peeking" into the instantiated XmlHttpRequest object. Without using locks, this is fundamentally a flawed designed bound to bite you and/or give youi intermittent "odd" behavior or inconsistent results. 3) It ignories the state machine of the protocol and any optimize/ improvings it may do, and/or any future transparent considerations it may make, i.e, fix a leak, optimze it, etc. Take a look the WC3.ORG specification: http://www.w3.org/TR/XMLHttpRequest/ You (speaking in general) don't want to go against the described protocol state machine (the flow and steps). You want to work with it because that is how each conforming user agent (browser) MUST behave. Here is the key statement: "User agents may optimize any algorithm given in this specification, so long as the end result is indistinguishable from the result that would be obtained by the specification's algorithms." In other words, jQuery MUST conform to the specification protocol design expectation. Just consider the following example provided at the W3.ORG site.. You can't do this in jQuery:: if(this.readyState == 3) { print(this.getAllResponseHeaders()); } because the jQuery external method skips loading.step (3). Also, it appears jQuery is calling xml.open before establishing any call back. This seems to go against the written specification. Any callback should be established before the protocol is initiatiated with open. In short, by introducing a timer, the design alters the protocol specification and fundamentally violated one of the basic principles in multi-threaded and sychronronization designs. Sychronization 101 preaches "Thou shall not use Timers" to sychronize events. In this case, it using "time" to take a snapshot of a state that might have come and gone - scary! The only reason it appears to work is because jQuery is using the minimum resolution in intel machines called the quantum (10 -15 ms depending on the CPU type). This allows it to appear to it is sychronized in round robin fashion. In other words, it is illusion that it appears to work. I wonder what will happen if you lowered the resoluition to 1ms which in Windows can be done using BeginPeriod and EndPeriod mult-media functions. That might give further strenghten that it may work fine because the user-agent is now getting more context-switching. But its worth checking because this would only go to show how using the timer makes the design extremely sensitive to all kinds of unknowns. Finally, the idea of memory leaks issues is a non-issue. If it is a bug, its a bug and the vendors should be told about it. But the solution, I don't think was appropriate. I could be completely off base, but I find it hard ot believe this is "required." It is just goes against my grain to see a timer like this, why? To fix a leak? I will venture that this may contribute to some of the timer/event firing issues that may be "serendipitously" reported here. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com (personal bog) Wildcat! Interactive Net Server (RPC C/S Intranet Hosting System) Wildcat! Sender Authentication Protocol (AVS system). iFTP (Intelligent FTP) Silver Xpress Offline Mail System Platinum Xpress Frontend Mailer (P2P) On Aug 25, 3:58 pm, "Erik Beeson" <[EMAIL PROTECTED]> wrote: > Couldn't you just use beforeSend to intercept the XMLHttpRequest > object and add your own callback handlers to it directly? You'll have > to put up with all of the aforementioned memory leak issues, but you'd > get access to all of the state changes that you're looking for... > > --Erik > > On 8/25/07, Pops <[EMAIL PROTECTED]> wrote: > > > > > Dan, > > > Thats exactly how I do look at code - always. I am a commercial > > developer. Products are used across the board. It is was one reason > > we avoided using javascript for many years (or atleast not these more > > advanced levels). > > > In this case, I don't think setting a timer and bypassing the > > implemented xmlhttpRequest() state machine protocol would work > > consistently. To illustrate my point, you already get different > > behavior on what states are skipped and changing the frequency will > > give you different behavior. > > > On the other hand, each protocol is designed to behave to provide each > > state and it must be signaled - otherwise it is really broken and > > something the vendor must address pronto. That should not be jQuery's > > responsibility. > > > In my products development experience, when you begin to "kludge" in > > solutions to get around a specific vendor problem, while that may work > > in the interim, that generally invites inconsistencies. jQuery is > > not cross browser ready in my opinion. Far too many items are not > > being tested well enough with IE. > > > Of course, whats fundamentally different is the open source > > mentality. The idea of using open source is relatively new for me. > > All the old reasons for not using it, are the same if you catch my > > drift. Yet, that is the way it is today. Can't no longer ignore it. > > So it takes a different mindset to get use to it - the idea of > > accepting lower quality software "as is" (and I am not saying jQuery > > is low quality) than what it normally would expected to be in a > > commercial environment. Of course, being that is open source, give > > the community the power to analyze the code - and I can't help myself, > > its in my nature to look at these things. > > > You know whats difference? > > > Unlike the past with free software, no longer are you seeing the > > proverbial - "Its free, stop complaining." <g> > > > So thas good atleast - the "professionalism" is growing in the open > > source world. > > > -- > > HLS > > > On Aug 24, 10:17 pm, "Dan G. Switzer, II" <[EMAIL PROTECTED]> > > wrote: > > > Pops, > > > > >Ok, there is always a reasons for something. I appreiciate you taking > > > >the timeout to share it. > > > > One thing to keep in mind is that jQuery is intended to be a cross-browser > > > library. Just because the XHR object works one in one browser, does not > > > mean > > > it works correctly in all the browsers on all platforms. > > > > The goal is to provide a consistent behavior across all browsers and > > > platforms whenever possible. > > > > Just keep that in mind when looking at code... > > > > -Dan
