RIFE : Acceptable session support
This page last changed on Mar 24, 2005 by gbevin.
People have been asking why RIFE doesn't offer any direct access to convential sessions. Hence a detailed explanation about how we came to the current solution.
First, the reasons why RIFE disables access to conventional sessions.
One session id contains a state which gets modified throughout the whole application. Since a visitor gets the same id everywhere, when they press the back button or bookmark a page, the get to a previous location in the application's execution flow. However, it uses the session data of a later point. This can create unpredictable and unwanted behavior.
Coders just tend to throw everything in them that they could need later. However, once it's in there, it's very difficult to decide when to take it out. It's also not trivial to see which parts of a site actually need which session parameters, so everything just tends to be left dangling around.
This is a very minor point and since it's virtually impossible to avoid this with any server-side state preservation engine, it's not a real problem. The real problem is that, without RIFE, passing data around through regular query parameters is cumbersome. Therefore, sessions tend to get used also for data that should in fact transfer through the URL.
However, sessions do have several advantages, that can't be done without a server-side state preservation solution :
There are applications where it's important that the visitor can't see the data that is transferred. This can be either for security reasons or for esthetical reasons. Imagine for example that you receive a credit card number, one that some additional steps are required later on before it's actually being used. It's surely discouraged to have this number being transferred back and forth, clearly visible to everyone and possible to bookmark or cache! Using a custom temporary database storage mechanism can be used to solve this manually, but it's not exactly developer-friendly or time-reducing.
Carrying parameters around through the query string or HTML forms is not without a cost. It does consume bandwidth and needs to be transferred back and forth. This can become a problem for large amounts of data. Additionally, URLs (and thus query strings) are limited in length. This can cause a application to stop functioning correctly if the limit kicks in.
Imagine for example that you create a wizard-like approach for data-entry in a website. You have to request the user to each time fill in the next part of the data that's required. Though you can use beans in RIFE to fill in data in a single entity that's automatically passed around, it mandates that all the data (from the start) is each time validated for every step in the wizard. Using validated beans makes this again easier, but it's not exactly the most developer-friendly approach and demands some redundant coding. Sessions make it possible to store the received data on the server and to be sure that it hasn't been modified through the client-side (hence it doesn't need to be totally validated at each request).
Consider the following points :
|Document generated by Confluence on Oct 19, 2010 14:56|