5 Replies Latest reply on Sep 3, 2006 9:52 PM by Matlus

    Making synchronous Http calls

      How would I go about making synchronous http calls using either the HTTPService class or URLRequest/URLLoader classes?
        • 1. Re: Making synchronous Http calls
          ntsiii Level 3
          You can't.

          All data access is asyhchronous.

          • 2. Re: Making synchronous Http calls
            peterent Level 2
            What Tracy says is true. Don't even bother trying, it is one of the atomic principles in the Flash Player.
            • 3. Re: Making synchronous Http calls
              Matlus Level 1
              Yes, I figured that one out. It's too bad really, the lack of choice I mean. Even in JavaScript one has the option to use synchronous or async calls.

              I'm assuming that the number of simultaneous calls (http) is limited by the browser (seeing that the whole http stack seems to be the browser's) which is normally limited to 2.

              I'd like to have the choice to decide which mode I'd like to use when.

              • 4. Re: Making synchronous Http calls
                peterent Level 2
                There is a huge penalty for remote synchronous calls. What happens if the call takes a long time because of network traffic? What happens if some of the data arrives, then there is a long pause, then more data arrives, etc.? Your client app is sitting there, blocked, unresponsive. Experience has shown that while it is nice to program in synchronous mode, it is ultimately bad for the application and the end user.
                • 5. Re: Making synchronous Http calls
                  Matlus Level 1

                  In principle I am completely for asynch calls. However, I'd like the option to go synch when I need/choose to. I don't want to use a tool that dictates what I MUST do. "Give us a choice", is all I'm saying.

                  I can argue for or against asynchronous calls. I've been doing TCP/IP for over 10 years and in my experience, I've required both.

                  Taking your points and making a case *for* synchronous calls:
                  Either ways, the user has to sit there till she sees the data and is able to proceed. Just having a responsive UI is absolutely no use to the end user. So great they can drop down combo boxes (that are yet empty) and click buttons but they're not able to get their work done :).

                  Further, as I noted, due to the fact that Flex uses the browsers http stack and that that stack is limited to 2 simultaneous calls, you're still waiting (no matter how you dice it). IO bound processes are ideal for multi-threading situations and yet we get only two.

                  We don't get the option to spaw our own threads and that's the first issue I have (with Flex). In the "real world" I would spawn my own thread and then make synchronous calls (due to dependencies that can't be helped), while the user get's a completely responsive yet useless UI.

                  Using your argument (once again) about responsive UI and all that. Where are my threads? I mean, are you saying that remote calls are the only case for ansychronous processes? I can think of a ton of things I'd like to do in the "background" (and they have nothing to do with RPC) but I can't since I don't have the option to spaw threads of my own.

                  Anyway, I'm not arguing about the merits or demerits of asynch/synch programming model. I'd just like the option to choose. Every programming tool I've used has given me this option and I'd like to see this in Flex too :).