Building responsive sessions
Written by mufasa
First, what do I mean by sessions? The HTTP request/response model is supposed to be stateless but the vast majority of page requests employ some form of state, whether it’s for advertising or saving application state, implemented by using cookies or javascript. I take it as a given that this type of session state is necessary and would like to make these sessions as responsive as possible. Either because of network or rendering delay caused by the bloat of the current web stack, most sessions on the web are not very responsive. Developers today work around this using various hacks like AJAX or COMET but these often involve bringing in additional problematic technologies like flash or silverlight. A new thin client would take this into account from the beginning by being designed for responsive sessions from the get-go.
First, we have to let go of the page model. Every object on the screen should be able to be updated independently, just as AJAX tries to let the browser do now. This may cause some problems for the URL concept but URLs can be reworked to be used in different ways (I’ll write more about reworking URLs later). Second, we have to allow the connection to be stateful, as that describes most usage of thin clients. Remember, TCP is stateful and most network traffic runs over TCP, so it can be done efficiently. Third, we have to focus on rendering speed on the client and ditch all VM-based languages like javascript, silverlight, and java. Those languages have no place in a thin client anyway, as a true thin client only deploys graphical/view data. Finally, someday this may necessitate deploying new network protocols but for now I’m sure current protocols like TCP, SCTP, and IP should do the job.
We can do so much better at creating a usable thin client experience than we are doing now. Only apathy and ignorance cause people to continue using the outdated tools of the past rather than trying to build better tools and platforms. A new thin client could do this.
Questions:
- How else can we make a responsive thin client?
- Why was request/response used for HTTP/HTML in the first place? Other than the fact that that is how it was originally designed, as it was created for moving large scientific datasets, why didn’t Netscape and others move to a more responsive session model during the evolution of HTTP/HTML in the mid-90’s?