On Fri, Sep 19, 2008 at 8:29 AM, Brantley Hobbs <[EMAIL PROTECTED]> wrote:
> > Guys, I'd like to offer one more time that perhaps this shouldn't be > deprecated and (eventually) removed. Admittedly the two examples that I > offered are "hackish" (don't get me wrong...I know the "right way", down > with procedural and up with event driven, etc.), but what is wrong with > offering more fine-grained control to developers? It's still not clear > to me what is inherently "evil" about a synchronous call. If a single > line "bad" synchronous call can effectively and efficiently do the job > of an additional 50 lines of code (putting up a transparent div, > handling events, tearing the div back down, etc.), why not use that? It > seems like a more efficient solution. > > My $0.02: Make it a pain the rear to use if you want, but leave it in > case someone needs or just wants to use it. > > I will now get off my soapbox and be silent in the corner! :-) > I agree with Michael and William that we should remove synch call support going forward. Users that still want to use synch calls can simply use the old JavaScript from 1.3 or 1.2.x. It should still work fine with 1.4 (because it's all JSON-RPC anyway.) In fact, you might be able to use anyone else's JS front end, as there are other alternatives out there. Those won't work with our extensions over JSON-RPC (fix ups, etc.) though. Synch calls are extremely bad practice and should only be used for toy or hackish apps like you mentioned. Can you come up with an example that isn't hacksih? Just as Michael has, I have all too often witnessed my programmers taking short cuts using synch calls when they should be using async calls. I've finally got everyone understanding the issue and on board with doing everything the async way. Synch calls lock up the entire browser (including the redraw thread) until the call returns. If the call returns immediately, you don't normally notice it and it isn't a problem. Try doing a sleep for 15 or 20 seconds, and you'll see how much of a problem it is. JavaScript in the browser is all single threaded, so nothing should block. You should instead redesign your app to be async, event based. If you don't want to do that you can always use the 1.3.X version of the Javascript client against the 1.4 server. I had even suggested (and Will agreed) that we keep jsonrpc.js around for awhile and make the new updated client be named jabsorb.js so the old version would even be included in the 1.4 distribution. We just won't maintain it going forward-- but people could have the option of using the old client (although it would be less supported going forward.) Is that enough of a compromise for you?
_______________________________________________ Jabsorb-dev mailing list [email protected] http://lists.jabsorb.org/mailman/listinfo/jabsorb-dev
