Brandon, Very true. Not everything is so cut and dry.
This one, no doubt in mind, is not a good idea. I won't say that if I didn't mean it, and I only say that because threads sychronization design is one my areas of expertise. I just took a look at prototype.js and mootools.js, neither are depended on a "Lets hope if this best guess 13ms always works" timer concept. Like I said to John, you might as well make that 1ms (not 0ms) because the non-RTOS system will automatically step to the next quantum (10ms-15ms). Assuming the machine quantum is 13ms, if the frequency was changed to 14ms, the actual the time slice is 26ms. If 27ms, the time slice is 39ms, and so on. But if the user was still using 95, a quantum of 10ms, a frequency of 13ms is actually a 20ms delay. Keep in mind that XHR implementations is also based on its own delays, sockets delays, and lets just assume one block of XHR block took 45ms, that means the OS/CPU would done atleast 3-4 wasted context-switching with jQuery 13ms frequency. The point is something - jQuery is playing with fire. None of the other two popular ajax apis are using such logic. And my final point on this thread, the memory leak that I see is related to clearing the XHR callback, which is understandable anyone can originality miss that. But jQuery is not using the XHR callback. So that should had not been an issue. Anyway, thanks for your excellent point. -- HLS. On Aug 25, 6:41 pm, "Brandon Aaron" <[EMAIL PROTECTED]> wrote: > 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
