> But by unsupported do you mean just deprecated or to be completely > removed? I would propose that support is completely removed . Users > requiring synchronous calls could always stay on a 1.3.x maintenance > branch. >
My plan was to completely remove them so that there is no possibbility of "accidentally" calling it, as you mention below. If people really really really want sync calls I was thinking that another javascript file could be included that was overload the async calls to be synchronous, but that is a bit of implementation I would prefer not to have to do. As you say sync users can stay on 1.3. > The main problem from my personal perspective, having a quite large > code-base using jabsorb, occasionally a developer on the team takes a > short-cut and makes a sync call (against our coding rules) and I'd like > to catch that. > > If it was still possible to use sync calls (say by enabling a tunable on > the client) it should at least be disabled by default, and an exception > thrown if no function callback is provided so these bad practices can be > detected. > > Currently we are propagating an easy interface to enable bad browser > programming practices whereas most other such AJAX libraries provide no > interface at all for these evil synchronous calls. I must say I have to > take a little blame for having this mechanism enabled on the original > json-rpc-java. > > > > > I for one actually do use synchronous calls. Perhaps it is an edge case > > (and perhaps I'm a nut case :-), but I use them for at least the two > > following scenarios: > > > > 1. I have an app written to test server session clustering. This > > consists of an AJAX call to the server farm that bumps a variable in > > session, then a read to see if it updated on all the cluster nodes (an > > independent read on all nodes). If the AJAX call is asynchronous, it's > > likely that the modification might not have propagated across all > > cluster nodes before the "read" call occurs on each node. > > > > You can still write code to simulate completely synchronous behaviour > using async calls. > > From the client POV, their is little difference from calls made in the > completion callback of an async call, than the statements made directly > after a sync call. > > You just need to re-organise your code so that code after an RPC call is > moved into a callback function closure. > > The primary difference will be that the browser is not completely locked > up during the call, so other events (keyboard, mouse) can cause JS > callbacks before your RPC call has completed. A common technique to > avoid this if needed is to have a utility routine to put up and tear > down a transparent div over the page to captures events while these > calls are in progress (and remember to hook > JSONRpcClient.toplevel_ex_handler to tear down this div). > > > 2. I have actually used AJAX calls to create a javascript sleep() > > method (the server takes the passed in parameter and sleeps on that > > thread for that amount of time). Wise? Perhaps not, but it does work > > and only because the AJAX call is synchronous. > > > > I see. The reason a synchronous sleep does not exist in JavaScript is > the same as the reason why synchronous usage of XMLHttpRequest is bad. > > Look at JavaScripts setTimeout() and clearTimeout() - same as 1. - it > requires that you move code directly after the sleep into a callback > function closure. > > I know it sounds like a lot of work but it is the right way™ of doing > things in an event-based programming environment like the web browser. > > Michael. > > _______________________________________________ > Jabsorb-dev mailing list > [email protected] > http://lists.jabsorb.org/mailman/listinfo/jabsorb-dev >
_______________________________________________ Jabsorb-dev mailing list [email protected] http://lists.jabsorb.org/mailman/listinfo/jabsorb-dev
