Prior to the advent of the World Wide Web, if you wrote a computer program, you could be assured that when you sent or retrieved data to/from a user session, the data was actually being transferred to that session.
This assurance was primarily due to the fact the computer terminals were hard-wired to the mainframe, and were not likely to be moved. Even with programs that are designed to operate on a modern network, the application protocols have state maintenance built in; you didn't have to worry about this aspect of the environment.In contrast, when programming Web applications you are relegated to using the HTTP protocol, which is stateless by its very nature.
This article will explore the fundamentals of maintaining session state so you can deliver a richer, more interactive Web environment to your users. It will attempt to bridge the gap between sessionless, static Web pages, and today's interactive environment of computer operating systems and programs.I'll look at how session state is handled in non-Web environments, and how it differs with HTTP environments. I will examine specific methodologies for maintaining session state, and briefly compare PHP's session functionality with the functionality of other languages. Finally, I will demonstrate a very simple method of maintaining state using a Web server's default document feature.
Read more about Maintaining State on the Web An Overview at http://www.buzzycode.com/ShowArticles-id_415.aspx
2007-06-21 23:18:32
·
answer #1
·
answered by Anonymous
·
0⤊
0⤋
See that article, basically it is right on everything, JSP, ASP, PHP, nearly all server programming/scripting framework use cookies by default to do that, Perl obviously exception to that. Although more precisely it was maintaining terminal and the state is more of internal programming on the server.
2007-06-22 07:18:23
·
answer #2
·
answered by Andy T 7
·
0⤊
0⤋