An explanation, if you don’t know what sessions are.

The basic design of the web is stateless. Every transaction is independent of every other transaction. But we want to have an ongoign conversation with the user - when they put something in their shopping cart, we want to remember it.

Enter sessions. We give the browser a unique number (usually as a cookie) that they give back to us. We then look up the data associated with that session number, and we have the user’s data. Of course eventually memory would fill with sessions, so we delete old sessions. If we don’t have the data for a session ID, we just start a new one. You can see this by going to a site, putting something in a shopping cart, then not coming back to the site for months.

8.1. Basic Session Usage

Session example This section uses file session_example.pl

At this point you’re probably fantasizing about all the stuff you can make in SWI-Prolog web, but you know you’re going to have to track sessions.

Sessions are ubiquitous on the web. I assume some of you understand sessions, but for those who don’t -

When a user visits a web page, they’re handed a cookie, a code they’re supposed to hand back to the server with the next page request. So you visit the fluffy bunnies site, and you’re given 3472723

You ask for another page, and your browser sends along cookie 3472723. The server knows you’re user 3472723 and can customize the page for you.

The classic example of this is shopping carts. You click a link to put a beany baby in your shopping cart, and the server now has a data structure 3472723 has a beany baby in their shopping cart, and when it generates the page it puts 1 over the shopping cart icon.

Eventually, of course, the server gets rid of the session. Usually after 30 minutes or so without hearing from the user.

The example provided with the tutorial gives the user a silly name. Once the name’s established, it will be used on subsequent visits as long as the session lasts. Most systems keep sessions about 30 minutes after the last activity (its settable in swi-prolog).

Whats going on under the covers is that the first httpRequest includes in its' response a set-cookie header with a random number. Subsequent requests pass this cookie back to the server, so the user gets a persistent identity. Now data can be associated with that identity using http_session_asserta and http_session_data

Implementing session control is insanely simple. More fun than Python

:- use_module(library(http/http_session)).

Wait, no, cmon, it can’t be that simple!

Yup. It is. You got sessions.

You know that lovable school/military/fascist youth camp tradition of giving people horrible nicknames? Ones they could never change? You didn’t find it lovable? Me neither.

Lets build a site that gives people more affirming nicknames. Of course, once we pick their nickname, they’re stuck with it as long as their session lasts. Right, Oh Blessed One?

Each request has a current session. That session has it’s own knowledge base that can be controlled with http_session_assert , http_session_retractall , and the obvious analogous calls, and queried with http_session_data/1 . It’s elegant and easy.

So, for our example, we’ll check to see if we’ve given this person a nick. If we find one in their session data, great.

nick_name(Nick) :- http_session_data(nick_name(Nick)),!.

If not, we’ll make one and assert into the session data

nick_name(Nick) :- nick_list(NickList), random_member(Nick, NickList), http_session_assert(nick_name(Nick)). nick_list([ 'Gentle One', 'Blessed Spirit', 'Wise Soul', 'Wise One', 'Beloved Friend' ]).

Exercise: Run the server. Reload the page several times. Completely exit SWI-Prolog and rerun the server. Confirm you can get a different name this way. Exercise: Add another handler that lets you reset your nick without restarting the server. Use http_session_retractall to get rid of the old nick. Hint - you can just recurse into the handler to get the new one.

We won’t cover it in this course, but you can control who gets a session. If you set the http_set_session_options create option to noauto you can manually create sessions. If you want you can set the session lifetime. This can dramatically affect server memory if have a typical distribution of visitors, with many arriving at a single page and a few staying.

You can also restrict which parts of your site cause a session to be created. This can be very useful for, say, an informational site that doesn’t need sessions for most visitors, but includes a small online store selling cafe press mugs and so on and needs sessions for the shopping cart.