Invest heavily in a FAST database for storing session ID's (i.e. really good indexing routines), one that can hold a lot of session variables and access them quickly. You will be keeping them around for a LONG time. Neat approach; I like the concept.

Test your session table with millions of rows. If you plan to have the site persist for years, you will need to have some sort of "last visited" date stamp so you can kill off sessions that are over X months old (i.e. they aren't coming back).

Accessing the site from public terminals will create a problem in that subsequent users will not see "old" data. That may or may not be a concern to you. Consider a "new visitors click here" thing to allow them to reset what the system considers new for that browser.

You also need a really good hash algorithm to generate unique session tokens because you don't want them to repeat by mistake.

The framework I would use is as follows:

• each navigation session in your site (identified by a cookie or passing a parameter from page to page) constitutes a session-object. This is a standard technique and you may find helpful info with a little search. Sessions should have an expiration time.
• each registered user has a profile and some data associated. The user-object is created on registration and stored somewhere. It doesn't expire (or does, but only after a long time).
• when the session starts and you cannot determine if the user is known to the application, you start with a new "anonymous" user-object linked to the session. You record the data in this user-object.
• If the user logs-in, then his stored user-object is retrieved and his data and preferences are merged with those stored in the current anonymous user-object. This way, if the user has selected a new 'preferred language' or has filled a form before logging-in, the info is not lost but kept for future use.

Hope that helps

Sounds like an okay idea. It might take some time and some work (and what website doesn't, right?), but you might have something going here. Now, the one thing that springs instantly into my mind is keeping track of data for non-registered users and registered users. Using a database, if you didn't want to have separate tables for registered and non-registered users, here's an idea I propose:

• First, use a sessions table. The primary key would of course be a session ID (perhaps created with Digest::MD5 or some similar module). This table would also contain a 'user' field, saying who this session belongs to. The table also contains session-specific data (data that only has to last the duration of the session, if there is any).
• Reserve a particular username pattern for non-registered users. This way, non-registered users can have the same sort of database entry as a registered user. Simply reserve names like 'anony_xxxxxx', where xxxxxx is a number. Set a blank password for these user's entries, so that a login isn't required. When a non-registered user comes along for the first time, create a new 'anony_xxxxxx' account and a new session, mapping that session id to that browser's cookie. Simply don't allow true logins to these special accounts. This might not make sense to you as I said it, it's hard to describe...
• One problem I forsee here is users that may use multiple browsers on the same machine, or they might clear their cookies out once in a while. It would be frustrating to lose all your information because you decided to throw your cookies away.
• I'm sorry to say this one (okay, only a little sorry): if somebody really wants to use your services and be capable of keeping information for a duration longer than the existence of a cookie, they will register on your site. May I even dare to say that if you lose people because you require them to register, then the people you lose weren't really into the site as much as you might have hoped. Besides, those people with these 'non-registered' accounts on their home computer probably won't be happy when they try to 'login' on a different computer, just to find out that they cannot access their previous session. :) I think it really depends on what content you provide on your site. For example, I cannot imagine perlmonks being a site with these 'temporary accounts'. What good would that do for a site like this? :)

If the above content is missing any vital points or you feel that any of the information is misleading, incorrect or irrelevant, please feel free to downvote the post. At the same time, reply to this node or /msg me to tell me what is wrong with the post, so that I may update the node to the best of my ability. If you do not inform me as to why the post deserved a downvote, your vote does not have any significance and will be disregarded.

Ugh, please don't pack your data columns like "anon_xxxx". Use the DBMS. Create an anonymous column of type boolean. You really need to normalize this table heavily. See any good SQL intro on rationalization/normalization. Otherwise you are going to take a serious performance hit. Consider these two tables: Users ("anon_xxx" used in id)
id, data

vs.

Users (boolean flag)
id, anon, data

In the first example, to retrieve a given username, your perl code has to retrieve EVERY row, split the id field on "-" and check for a match.

In the other example you simply ask the database for the row(s) "where id = $userid and anon = false". The database will be much faster because it can use indexes to skip a great deal of the records and quickly zero in on the user id of your choice. Remeber, a good database (ala Postgres) will be written in C and is optimized for grinding through large amounts of data efficiently.

Sounds like you need a simple session object to keep track of things for you. This would have a session id that can be passed around via cookies or by the URL. Then you use that session id to reanimate an old session or create a new session if one isn't already found. Here are a few things to chew on:

• You definately want to use a database. Which rdbms is an exercise left up to you as you know your requirements best.
• use Digest::MD5 qw(md5_base64) to generate your session ids. Start with something like md5_base64(localtime() . rand() )
• If everything is going to be perl, use your backend storeage to store your session objects data cargo serialized (use Data::Serializer for example). This will simplify your initial module letting you get on to the juicier parts. Keep your interface clean and simple so that you can swap this out later if needs be.
• Don't forget the useful things to track such as the last requested page, ip address, time, etc. This is a great opportunity to unify your session handling with some form of db logging.
• You might also benefit from the use of mod_perl.

You can easily roll your own, or take a look at Apache::Session.