• Problems of conventional sessions
  • sessions are not in sync with the application execution flow
  • sessions tend to become a waste-bin
  • sessions create meaningless URLs
• Benefits of conventional sessions
  • sessions hide the transferred data from the client-side
  • sessions prevent huge amounts of data to have to be carried around
  • sessions allow easy handling of progressive states
• RIFE's solution

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.

Problems of conventional sessions

First, the reasons why RIFE disables access to conventional sessions.

[top]

sessions are not in sync with the application execution flow

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.

[top]

sessions tend to become a waste-bin

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.
Also, a few months later, one doesn't really remember everything that's in the session so the 'fastest' approach is to start making up weird names to ensure that there are no clashes. Thus, unless the developer is very methodological and documents the session's impact and contents properly, it can become a horrible mess.

[top]

sessions create meaningless URLs

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.

[top]

Benefits of conventional sessions

However, sessions do have several advantages, that can't be done without a server-side state preservation solution :

[top]

sessions hide the transferred data from the client-side

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.

[top]

sessions prevent huge amounts of data to have to be carried around

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.

[top]

sessions allow easy handling of progressive states

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).

[top]

RIFE's solution

Consider the following points :

• RIFE leaves no doubt about the data flow at all, thus it can never get to the problematic and unmaintainable states of sessions. Data will never continue to be transferred further than needed and there's never a doubt what gets used and when.
• RIFE makes it easy to transfer data around through either data links or global variables. This reduces developer intervention to a minimum while still provided fine-grained and coarse-grained development possibilities.
• RIFE supports web continuations which make handling progressive states extremely easy.
• RIFE transfers everything by default through the client-side and makes the URL or HTML form drive the application.
• RIFE allows state storage to be done on the server-side through its configurable state storage mechanism, while still using all the data flow features. This allows sensitive and large data to not be transfered back and forth.

[top]