Re: P5EE Sessions

I think I have to agree with YAGNI.

Just use Apache::Session for now as a placeholder if you need session 
capability (or better yet one of the Cache modules) and then if you find it 
being used too much, perhaps then it would make sense to develop a real 
session system.

Having developed session logic that supports the Java Servlet API 
(Extropia::Session being more complex than Apache::Session), I can tell you 
that it is quite a non-trivial task. Yet I think the session needs in the 
servlet API are really in retrospect mostly unused in Perl programs.

Also, Perl operates a bit differently with regards to sessions because the 
repository is not through a single multi-threaded engine which makes Java 
sessions usually very easy. The moment you have to deal with replication 
and the like, everything becomes more complex. :)

I think I got a greater win for my programming time (for example) in 
designing a modular authentication and authorization structure to allow us 
to quickly slot our apps into any system from smartcard authentication to 
username/password CGI form logons using session keys and from LDAP backends 
to SMB/NT server backends. Yet it took me about the same amount of time to 
code.

If you don't like the idea of using Apache::Session, just write a thin 
indirect layer on top of it for P5EE::Session. You can always add to the 
API later.

One thing I would disagree with on Rob's thing below is that a session is 
just a is just a web browser instance associated with a set of data. 
Sessions can be more than just passed over a single browser. You can always 
have a session that is shared amongst many users to cache data that you 
would like to eventually expire when the user load goes down for example.

A session, is, well... a session. :) How you manage those sessions (user 
cookie, form variable, or across a larger set of users as cache is up to 
your session manager code IMHO...:)

Later,
    Gunther

At 12:48 AM 6/20/2002, Rob Nagler wrote:
>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

__________________________________________________
Gunther Birznieks ([email protected])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Office: (65) 64791172 Mobile: (65) 96218290