Re: P5EE Sessions

Stephen Adkins writes:
> I mainly expect feedback from Rob Nagler on this, who
> suggested that sessions should not be a part of P5EE at all.
>    http://archive.develooper.com/p5ee%40perl.org/msg00951.html
> I would appreciate his feedback on this along with
> alternative suggestions for how to build an application
> without a "session" concept.

Well here ya go.

My definition of a session is ephemeral state associated with a
browser.  You store a session id in a cookie and put stuff in the
session object on the server which you know about the browser (auth
info, timezone, cart items).

> I took it so be self-evident that every application of any
> significance needs to incorporate the concept of a "session".
> That is, from the time of first contact of the user with the
> application, the accumulated results and the resulting
> application state is the data that make up the session.

In the PetShop, we assign a cart id when the user first clicks "add to
cart".  You need a cart object to hold the items.  This is pretty
simplistic and essentially a "session", because we need to empty the
cart at some point.  However, the data is normalized in ordinary
tables.

This was a quick hack.  In our bivio.com app, we create a visitor id
for each browser.  This is not ephemeral state, i.e. it never
expires.  If the visitor becomes a user, we associate that visitor and
the user.

If you have ephemeral state, e.g. 'lost password temporary passwords',
these need to be garbage collected, but they aren't part of a
session.  Or perhaps, you have subscriptions to your site, which need
to be expired on the appropriate date.   Your application needs to
manage the expirations.

> For most applications we grew up developing, there was no
> particular need for a "Session" object.  The program memory,
> with all its variables and their values, made up the 
> state of the application or its "Session".  However, stateless
> HTTP-based web applications require us to explicitly save and
> restore the application state and remember where we stored it,
> usually with a session id.

NFS is a stateless protocol.  However, the data is not stateless.  You
need to manage data, but this doesn't have to be collected into one
object called a "session".  Rather you assign a unique id to the
browser or user which is a foreign key in lots of tables.

In bOP, we trust the encrypted data in the cookie comes back
unmodified.  We don't trust anything about the relationship to that
data and the data in the database.  This means we authenticate the
user_id and the user's role in the realm she is operating in.  All of
this is server-side and executed on every request.

> Thus, web applications forced us
> to introduce the concept of a Session explicitly, but this
> does not mean that a framework with a Session object as
> a core service is web-centric.

This forgets history.  The Web is nothing new.  The same problems had
to be solved in any OLTP application (airline reservation systems
being the prototypical example).  I'm most familiar with Tandem's OLTP
infrastructure called Pathway.  All messages in Pathway were stateless
until Open Market's WebServer was ported to Tandem.  They needed a
stateful protocol to handle CGI applications, because the max message
size was 32KB.  Apache, fortunately, does not have this constraint.
All "standard" Pathway applications (ATM networks, mail switches,
NYSE, etc.)  communicate with their clients statelessly.

You don't need a session object.  You do need server side state which
is associated with a user or visitor.

> Requiring all P5EE applications to use a Session would allow
> for many nice features.

YAGNI.  Wait for it to come naturally.

> In comparison with Java/J2EE (and I am not a Java expert),
> J2EE defines three kinds of Enterprise Java Beans (EJB's):
> Stateless Session Beans, Stateful Session Beans,
> and Entity Beans.  Perhaps the P5EE::SessionObject is like
> Session Beans, but each SessionObject gets "statefulness"
> by default, although they may choose not to use it or
> store anything there.

I am a Java expert imiho. :-) Enitity beans are a joke.  Stateful
session beans are probably just as bad.  Stateless session beans are
transaction containers for business logic and re-invent what Pathway
and IBM CICS has been offering their users for many years.  The theory
is that because it is in Java, it's better.  For your typical IS, Java
hurts more than it helps.

Rob