Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 9 of 9
  1. #1
    hgs
    hgs is offline
    New Coder
    Join Date
    Jan 2010
    Location
    Germany
    Posts
    81
    Thanks
    3
    Thanked 5 Times in 5 Posts

    timeout for async http request only, why ?

    Why can I not specify a timeout for synchronous request also ?
    This is in my opinion a serious design flaw.
    All the world and his brother is touting to stay away from
    synchronous request but....

    When a user is working with a database via synchronous requests
    he can be sure the transaction is complete, or he
    receives a message from the database that something is wrong
    so the user can decide,depending on the responds, how and if to carry on with his work.

    In fact there are situations when I have to block the user from interacting
    with the web application until the back end has responded somehow.
    That is why I prefer using synchronous requests, here blocking comes for
    free.

    However, I ran in situations where the back end did not respond for
    whatever reason, so the web application is blocked forever, as well as the user.

    Here it would make perfect sense to be able to specify a timeout and
    a function for the ontimeout-event. Then I could say , that if the
    back end is not responding within 100ms my ontimeout-event starts working
    by alerting the user and I kill the pending request.

    Meanwhile i have an ugly solution by using async requests, some homegrown
    modal dialogs to block interaction with the web application and setTimout() and clearTimout().

    So please educate me why this has to be like it is.

    Regards
    My site
    If you’re doing software development right, you’re probably doing Agile wrong.
    -- Isaac Schlueter

  • #2
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,293
    Thanks
    10
    Thanked 583 Times in 564 Posts
    if you're using GET, then it's pretty easy. If you're using POST, then you can still convert your ajax to a hidden form, which you can cancel during the submit process. but, it's really much better for the user to use async programming anyway. there is little advantage to ajax, maybe 1/3rd of sec per task over server-side processing, if you use sync requests: the user still waits on a server instead of starting their next sub-task...
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #3
    hgs
    hgs is offline
    New Coder
    Join Date
    Jan 2010
    Location
    Germany
    Posts
    81
    Thanks
    3
    Thanked 5 Times in 5 Posts
    Quote Originally Posted by rnd me View Post
    if you're using GET, then it's pretty easy. If you're using POST, then you can still convert your ajax
    to a hidden form, which you can cancel during the submit process.
    Can you please elaborate on this , I am not sure what you mean.


    Quote Originally Posted by rnd me View Post
    but, it's really much better for the user to use async programming anyway. there is little advantage to ajax,
    maybe 1/3rd of sec per task over server-side processing, if you use sync requests: the user still waits
    on a server instead of starting their next sub-task...
    I am using async as well as sync. Of course a user should not be forced to
    wait for the appliciation, but sometimes there are reasons to have him wait.

    However the question still is :
    Why can I not specify a timeout for synchronous requests, what is the reason
    for this ?
    My site
    If you’re doing software development right, you’re probably doing Agile wrong.
    -- Isaac Schlueter

  • #4
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,293
    Thanks
    10
    Thanked 583 Times in 564 Posts
    Quote Originally Posted by hgs View Post
    Can you please elaborate on this , I am not sure what you mean.

    Why can I not specify a timeout for synchronous requests, what is the reason
    for this ?
    browser makers often enforce certain procedures to keep programmers from making mistakes. sync is sync, and it lives up to it's name. the whole stack freezes, setTimeouts and all. in the case of sync, the browser transfers all processing into the hook, so there is no way it can check how long it's been without aborting. it's also a great way to encourage user to open your app on more than one tab so they don't have to wait on your slow screens. If you are having sync issues on the back end, i can't imagine that a 2nd tab would improve things. try to avoid timing fragility using state management and system-wide input validation.


    if you feel that adding async will complicate your project, you're likely not approaching asyc right. it should only add a line or two to an existing routine since javascript has closure and you can simply wrap the 2nd-half of your sync code with an anon callback that defines the response as a parameter instead of a local var. whatever you did after the sync call, you do in a callback, which can live in the same code spot as before. it really shouldn't take much effort, and the payoff for everyone are huge. you'll be hard pressed to make another single-sitting change that would have as large an impact on the perceived quality of your code.

    i used to argue strong for sync to, so i'm not just being dogmatic, i learn the hard way (as you are now) that it's better to bite the bullet and do things that won't cause confusing errors like the browser not responding to menu clicks.


    to elaborate on what i mentioned, you can use an iframe to submit, and you can re-nav the iframe anytime, unless you use sync ajax. you can also use an image PING or script[src] to ship GET data, and those can be aborted as well. showModalDialog can use ajax on its dialog, and you app will wait on the modal like it does a sync ajax request. you can close the modal from inside the modal and communicate with it use localStorage. yeas, its a huge work-around and it's easier and better to use async techniques in event-driven languages like JS.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #5
    hgs
    hgs is offline
    New Coder
    Join Date
    Jan 2010
    Location
    Germany
    Posts
    81
    Thanks
    3
    Thanked 5 Times in 5 Posts
    Quote Originally Posted by rnd me View Post
    browser makers often enforce certain procedures to keep programmers from making mistakes.
    Good luck !

    Quote Originally Posted by rnd me View Post
    sync is sync, and it lives up to it's name. the whole stack freezes, setTimeouts and all.
    in the case of sync, the browser transfers all processing into the hook,
    so there is no way it can check how long it's been without aborting.
    Here they probably made a mistake...

    Quote Originally Posted by rnd me View Post
    it's also a great way to encourage user to open your app on more than one tab so they don't have to wait on your
    slow screens. If you are having sync issues on the back end, i can't imagine that a 2nd tab would improve things. try to avoid
    timing fragility using state management and system-wide input validation.
    if you feel that adding async will complicate your project,
    you're likely not approaching asyc right. it should only add a line or
    two to an existing routine since javascript has closure and you can simply wrap the
    2nd-half of your sync code with an anon callback that defines the response as a parameter instead of a local var.
    whatever you did after the sync call, you do in a callback, which can live in the same
    code spot as before. it really shouldn't take much effort,
    and the payoff for everyone are huge. you'll be hard pressed to make another single-sitting
    change that would have as large an impact on
    the perceived quality of your code.
    I know what you mean , bellow is a piece of code from myBackend.js package I am using

    Code:
     function callDirect(backEnd, sendPkg, respondAction) {
            var request, jsonPost = {};
            request = getFreexmlHttp();
            if (request) {
                if ((request.readyState === 4 || request.readyState === 0)) {
                    request.open("POST", backEnd, true);
                    request.setRequestHeader("Content-Type", "application/json");
                    request.onreadystatechange = function() {
                        if (this.readyState === 4 && this.status === 200) {
                            this.onreadystatechange = '';
                            try {// try to decode jason for the respond action
                                jsonPost = (JSON.parse(this.responseText));
                                respondAction(jsonPost);
                            } catch (e) {// backend delivered bogus json 
                                jsonPost.error = (this.responseText);
                                respondAction(jsonPost);
                            }
                        }
                    };
                    request.send(JSON.stringify(sendPkg));
                }
            }
        }

    Quote Originally Posted by rnd me View Post
    to elaborate on what i mentioned, you can use an iframe to submit, and you can re-nav the iframe anytime,
    unless you use sync ajax. you can also use an image PING or script[src] to ship GET data, and those can be aborted as well.
    showModalDialog can use ajax on its dialog, and you app will wait on the modal like it does a sync ajax request. you can close
    the modal from inside the modal and communicate with
    it use localStorage. yeas, its a huge work-around and it's easier and better to use async techniques in event-driven languages like JS.
    Many thanks for taking the time to respond.

    Regards
    My site
    If you’re doing software development right, you’re probably doing Agile wrong.
    -- Isaac Schlueter

  • #6
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,293
    Thanks
    10
    Thanked 583 Times in 564 Posts
    Quote Originally Posted by hgs View Post
    I know what you mean , bellow is a piece of code from myBackend.js package I am using

    Many thanks for taking the time to respond.

    Regards
    one unrealted way to improve the readability of callback code is to reduce over-all nesting. since you might use some nesting in your callbacks, we want to keep the function in check, lest it crawl further to the right than down; a sure sign that things could be simpler.


    at any rate, by combining some ifs and flipping them to cancel on bad and continue on good we can cut down on the "greater than symbol" distortion:


    Code:
    function callDirect(backEnd, sendPkg, respondAction) {
    
    
    	function onchange(){ 
    		// only continue when done without http problems:
    		if (this.readyState +"."+ this.status != '4.200' ) { return; }
    		try { // try to decode json for the respond action:
    			respondAction(JSON.parse(this.responseText));
    		} catch (e) { // backend delivered bogus json, echo it back:
    			respondAction({error: this.responseText} );
    		}
    	}; /* end onchange() */
    
    	var request = getFreexmlHttp();
    
    	// make sure we're valid and ready:
    	if( !(request && [1, 0, 0, 0, 1][request.readyState])) { return; }
    
    	request.open("POST", backEnd, true);
    	request.setRequestHeader("Content-Type", "application/json");
    	request.onreadystatechange = onchange;
    	request.send(JSON.stringify(sendPkg));
    
        return request;
    
    } /* end callDirect() */

    this results in a new max tab depth of three instead of six, a clear win for readability and scan speed.
    Last edited by rnd me; 10-29-2013 at 08:38 PM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • #7
    hgs
    hgs is offline
    New Coder
    Join Date
    Jan 2010
    Location
    Germany
    Posts
    81
    Thanks
    3
    Thanked 5 Times in 5 Posts
    Impressive, thanks !

    However ...

    Code:
    if( !(request && [1, 0, 0, 0, 1][request.readyState])) { return; }
    For us regular if-then-else folks, please, what the hell is this

    Oh and
    "greater than symbol" distortion
    Never heard . Care to explain ?
    Last edited by hgs; 10-29-2013 at 10:04 PM.
    My site
    If you’re doing software development right, you’re probably doing Agile wrong.
    -- Isaac Schlueter

  • #8
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,293
    Thanks
    10
    Thanked 583 Times in 564 Posts
    Quote Originally Posted by hgs View Post
    Impressive, thanks !

    However ...

    Code:
    if( !(request && [1, 0, 0, 0, 1][request.readyState])) { return; }
    For us regular if-then-else folks, please, what the hell is this

    Oh and

    Never heard . Care to explain ?
    1. yeah, i don't know how to use else ifs, never have in any language. the pattern shown is known as a lookup table, a white-list of allowed properties. you are selecting a slot of the array using readyState. if you select a slot that stores a 1, then the if statement is true because 1 is true. if the readystate points to a zero slot, then the if is false because 0 is false.

    since 3 elements is not much slack, i used an array, but you can also use an object for sparse numbers:
    Code:
    if({ 101: 1, 200: 1, 203:1, 404:1  }[ n ])
    the pattern works equally well for strings:
    Code:
    if({ bob:1, fred:1, jane:1   }[ userName ]) // look ma, no quotes!
    you can also use it to translate one value to another in a one-of-the-above scenario instead of using a switch statement:

    Code:
    var pickupDay= { tue: "wed",  wed: "wed", thu: "fri", fri: "fri" }[dropoffDay] || "mon";
    i've found that removing IFs makes your code run faster and easier to debug.

    2. i simply mean that your code points to the right. make the font size tiny, walk across the room, and look at your monitor. you will see the grater-than sign (>). you might need a bit of imagination. mine looks more like a bracket (]), which implies that it's less to dig through and has fewer parens/braces to balance as you expand it.
    Last edited by rnd me; 10-30-2013 at 12:37 AM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  • Users who have thanked rnd me for this post:

    hgs (10-30-2013)

  • #9
    hgs
    hgs is offline
    New Coder
    Join Date
    Jan 2010
    Location
    Germany
    Posts
    81
    Thanks
    3
    Thanked 5 Times in 5 Posts
    rnd me

    Once again many thanks.
    This gives me new ideas for my programming.

    Regards
    My site
    If you’re doing software development right, you’re probably doing Agile wrong.
    -- Isaac Schlueter


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •