Edward: Had a project from someone once and it was called "BruceLee", and I got it to install, I put these up since the instructions might be helpful to install any project when you have to link them to other projects, etc.

Edward: The buffer concept makes sense theoretically and I'm continuing to step through the code until I get the big picture of this application. One of the things I have to keep reminding myself of as I get into this application code is that it is not a website. I have pretty much always programmed websites and so for me there is never state, or at least if you need state it is an exception to the norm and you store it in a session variable and you have to be careful that you don't store too much in state, etc. In application programming such as Flex state is all around you, it is the norm, every variable you store stays there and will never go away. The concept of "page hits" and "server roundtrips" is gone. And you don't have to do any AJAX backflips to emulate it: state is just always there. This concept and the concept of the event model (e.g. you start loading an XML file and then go on processing while the XML file is not loaded yet, and only when it is loaded does it fire an event to start processes that use the data) are the two hardest things for me to get over as I switch from classic web programming to application programming.

guerkan: i think we have to differ two state types; persistent state and memory state. In flex we can work on the memory state which is present all the time. We can structure the memory state with classes and objects. This gives us a good link between our programming language and the memory state. Things starts getting complicated when we want to save data onto disk in flex or bringing persistent state from disk into the memory state of flex. Two types of forces makes it complicated in flex to close the gap between this two types of states. The first force is the slowness of the persistent state. We can't say in flex "load the data and work on them" in the same method call. This is due to the second force: response time of the user interface. That means, while doing one thing - loading data - flex can't do an other thing - getting user input and doing the presentation. This is one of the problems we encounter in real-time-systems like flex. We can use the flex event model to overcome this problem of response time. In that model, we start initiating loading of data and doing other work mean while (going back to the runtime and letting him do the presentation and input controlling). When flex is ready with loading, our code gets triggered again. Now we have just a few milliseconds doing work again. Otherwise the user interface (browser) would not response any more, because the runtime is busy running our code. A real-time-system is forced to use the faster memory state, otherwise it would loose too much processing time by accessing a persistent disk state. In standard web development (php, jsp), we are using business software. Here the requirements are unlike from a real-time-system. The business software should be able to response to a huge amount of requests from remote clients running on different systems. The fact of not having any state in the business software makes it more easy to handle the huge amount of requests. But no software can work without any state, so the state of a business software component is our request. Sometimes the state is send back to the client as cookies. Newer application server afford the concept of sessions where the state is kept on the server side for the same client. All types of state handling in the business software can be seen as a pesistent state (except session handling). In one scenario data is send to the disk and in the other one it is send to the client. Once the data is held by the disk and once it is held by the client. The persistent state handling is slow for a real-time-system, but good for business software. If the server breaks or any clients break, we can recover the state and keep on working. This is different in the flex game. If the client breaks, the user has to start in the first level again. In this conceptual view, ajax is getting the technology for closing the gap between a real-time-system and the business software. Where the browser keeps the memory state (dom model), makes the presentation and our code handles the user interaction. For streaming in new data from the persistent state to the memory state, we are using ajax. It's just for triggering the loading. Then we are going back to the browser and waiting to be informed by the browser, when the data is in memory state already. It's like flex, isn't it?