If only everything was so cut and dry. -- Brandon Aaron
On 8/25/07, Pops <[EMAIL PROTECTED]> wrote: > > > 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 > >
