P5EE Sessions

Hi,

I would imagine that the discussion of Sessions would be the
easiest of the three topics I plan to discuss before calling
for a vote.

The two propositions I am making and on which I seek agreement
or disagreement are the following.

  1. a Session class (and its subclasses) is a good central
     concept (what P5EEx::Blue calls a Core Service) on which
     to build a wide variety of Enterprise Applications
     (including Web Applications) and provides the desired
     flexibility of implementation

  2. a SessionObject class is a valuable abstraction for the
     implementation of business logic

You might want to review the Session documentation, although
please forgive its unfinished state and a handful of errors
already pointed out (like the html() method in the base class).

http://www.officevision.com/pub/p5ee/software/htdocs/api/
http://www.officevision.com/pub/p5ee/software/htdocs/api/Session-tree.html

SESSIONS

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.

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.

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.

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.

Requiring all P5EE applications to use a Session would allow
for many nice features.  Sessions can be serialized, sent over
networks and processing can be resumed on another system.
An application can easily save its state and resume later where
it left off.  Even command line invocations of the P5EE can be
connected together in a session, providing for much richer and
more powerful command line applications.

I have implemented two Session subclasses so far.
They are meaningful primarily for web applications.

   P5EEx::Blue::Session::HTMLHidden
   P5EEx::Blue::Session::Cookie

Other implementations are envisioned.

   P5EEx::Blue::Session::ApacheSession
   P5EEx::Blue::Session::ApacheSessionX

They each have pros/cons (particularly around the dreaded
Forward/Back and File->New->Window problems), but they
function and they illustrate that the central Session
concept may have multiple valuable implementations,
allowing the P5EE as a whole not to be locked into any 
one of them. (I use the "HTMLHidden" most of the time,
so "Cookie" might be broken at the moment.)

The Session::HTMLHidden utilizes no server side storage.
It serializes and compresses the session data structure
and "stores" it in a series of HTML <input type="hidden">
variables in the HTML returned to the browser.  These
variables are posted back to the server and the Session
is reconstituted before events are processed.  This allows
for stateful applications to be built in a world of 
stateless HTTP, and it would seem to satisfy the
"Rob Nagler Session Requirement" of "Shared Nothing".

The Session::Cookie utilizes no server side storage.
It does the same thing as HTMLHidden but stores the
compressed, serialized (encrypted, MAC'ed, yada yada)
session data in a series of cookies. Again, this has pros
and cons that you are no doubt familiar with, but it does
represent one meaningful implementation of a Session.

SESSIONOBJECT

My poor Widgets got bashed mercilessly in the feedback in
the last round.  So I have given a lot of thought to what
I was trying to accomplish.  I am proposing the basic
concept of a SessionObject.  I will discuss whether Widgets
should be a part of P5EE in a following e-mail.

A SessionObject is a non-visible object in which business
logic or application logic can be coded.  The real meaning
of a SessionObject is that its lifetime is the lifetime of
the Session, and its state is stored in the Session.
Wherever the Session is, all of the SessionObjects are
easily accessible.

SessionObjects are tightly integrated with the Session/Context.
They handle events initiated in the Context.  They live
within the Context.  To the user, they just exist.  The
Context has to worry about the physical life cycle...
when to instantiate them, when to serialize and store them,
etc.  In fact, SessionObject will form a base class for 
Widgets, but the name is much clearer that they are simply
objects which live within the session.  They are not to
be categorized as simply "user interface objects".

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.

(Sneak preview: What I used to call "Entity Widgets", I will
be proposing to call RepositoryObjects, to make clear that
they are simply objects whose home is in a Repository
(i.e database), but that's another e-mail.)