Why you need save-state
If you have a web site with only two (2) pages, you don't need save-state. That's because the fundamental nature of the web is to always pass data from one page to the next, and if you are lucky enough to only have two pages, then your second page will know everything from the first.
On the other hand, if your web site has more than two pages for the surfer to click through, and you want to be able to intelligently respond in various areas based on what the surfer has already done and told you, you definitely need save-state.
HTTP is stateless
This is adequate if you want to show only static pages, but it is completely unacceptable if you have an interactive site.
Think about it -- you've probably been to web sites where you had to rekey information; for example, entering your name and address to request information, and then having to enter it again to send a note to a sales rep. That happens because the site uses technology which does not completely/correctly save state. The consequences range from frustrated site users to lost sales.
WebHub tracks the surfer and adds state to HTTP
Before a web application can save-state, the application must first be able to accurately track the surfer as each page is accessed. Some systems (such as Cold Fusion and ASP) do this with cookies,which presents reliability and security problems. Since WebHub was first released in October 1995, WebHub has been tracking surfers through an anonymous number in the URL. This method is fast, easy and secure.
Session number and object
The session object keeps track of :
The time-sharing metaphor
The components (or objects) within all WebHub application servers are capable of remembering their own state. It's a little like time-sharing at a resort, where the component is the resort. A surfer comes in with a page request, and various components are used to create the page dynamically. For example, the TwhCycle component might get used to serve an advertising banner. The save-state mechanism makes sure that when the page is done, the surfer's session object remembers the state of that TwhCycle component. When the surfer comes back, no matter how many other people have time-shared that component, the state is restored so the component can accurately present the next ad for that specific surfer.
The bottom line is that WebHub saves state of all the commonly-required items and has an architecture which is by nature extensible, so that a VCL programmer can build in whatever additional surfer-specific properties may be needed over time.
WebHub Save-State demo
To see an example, bookmark this page then take a look at the Save-State Demo ("FORM"). It's a humorous example that shows exactly how much more WebHub remembers compared to a standard CGI or ISAPI application.
Cookies -- problems with refusal and security
There is the also the very serious problem of security. What if you logged into SecureTax.Com while you were at an Internet cafe and they had used cookies? (Fortunately, they don't -- they use WebHub instead.) If they had used cookies, the next person at the terminal could have gotten into your account (yes!). That's true at the office, too. Who uses your computer when you are away from your desk? Cookies are tolerable for information that is non-essential. They are totally inappropriate for secure facts.