Adam Thompson <[email protected]> writes: > In addition, given the way web 2.0 works, > we realy need to get rid of the manual timer mechanism sooner rather than > later > as otherwise timing critical ajax stuff can *never* work,
The problem is a mismatch between the way edbrowse works and the way the ajax web works. Edbrowse is very synchronous. The state of the program only changes at the user's request. Nothing really happens in the background, *ever*. Of course, that changed slightly with the addition of background downloads, but edbrowse is still pretty synchronous. This model is comfortable for some of us, including me. If I'm browsing a buffer, reading along, I know that the buffer isn't going to change out from under me. If it's going to change, it does so because I told the program to take some action. This is the teletype paradigm. On the other hand, with ajax, you have all kinds of things happening in the background. What happens if I'm reading along in my buffer and some javascript timer fires to update the page? Will I end up reading at the same place where I was? It's even possible that the thing I was reading no longer exists. It's very asynchronous. The Ajax model works well for GUIs, because GUIs are also highly asynchronous. So our ultimate task will be trying to smoosh the asynchronous paradigm into the teletype paradigm, also known as forcing a square peg to fit a round hole. -- Chris _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
