At 10:13 PM 5/8/00 +0100, Greg Cope wrote:
>: On Mon, 8 May 2000, Leslie Mikesell wrote:
>:
>: > According to Jeffrey W. Baker:
>: >
>: > > > I keep meaning to write this up as an Apache:: module, but it's
>pretty trivial
>: > > > to cons up an application-specific version. The only thing this
>doesn't
>: > > > provide is a way to deal with large data structures. But generally
>if the
>: > > > application is big enough to need such data structures you have a
>real
>: > > > database from which you can reconstruct the data on each request,
>just store
>: > > > the state information in the cookie.
>: > >
>: > > Your post does a significant amount of hand waving regarding people's
>: > > requirements for their websites. I try to keep an open mind when
>giving
>: > > advice and realize that people all have different needs. That's why I
>: > > prefixed my advice with "On my sites..."
>: >
>: > Can anyone quantify this a bit?
>: >
>: > > On my sites, I use the session as a general purpose data sink. I find
>: > > that I can significantly improve user experience by keeping things in
>the
>: > > session related to the user-site interaction. These session object
>: > > contain way more information than could be stuffed into a cookie, even
>if
>: > > I assumed that all of my users had cookies turned on. Note also that
>: > > sending a large cookie can significantly increase the size of the
>: > > request. That's bad for modem users.
>: > >
>: > > Your site may be different. In fact, it had better be! :)
>: >
>: > Have you timed your session object retrieval and the cleanup code
>: > that becomes necessary with server-session data compared to
>: > letting the client send back (via cookies or URL) everything you
>: > need to reconstruct the necessary state without keeping temporary
>: > session variables on the server? There must be some size where
>: > the data values are as easy to pass as the session key, and some
>: > size where it becomes slower and more cumbersome. Has anyone
>: > pinned down the size where a server-side lookup starts to win?
>:
>: I have really extensive benchmarks for every part of Apache::Session.
>: These will be released with version 1.5, which also includes more than
>: fifty new unit tests. Again the performance is very dependent on what you
>: are doing. If everything is on one machine and you are grabbing Storable
>: obejcts from the filesystem, you can retrieve and unStorable the object in
>: time on the order of 100 microseconds (600 MHz Intel/Linux 2.2). If you
>: need to get the object out of a database across the network, network
>: latency will add to that. In larger applications, I would use a private,
>: switch 100 Mb/s ethernet to access the shared backing store, so that
>: latency is not bad. Once again, it depends on your specific needs and
>: implementation.
>
>Butting in a little OT here but will v1.5 support the transparent use of
>additional path if cookies are turned off.
As far as I knew Apache::Session has never even had anything to do with
cookies. It is a persistent storage mechanism where the session "handle" is
a uniquely generated ID.
What you are interested in is a Session "manager" which understands how to
deal with the workflow around using a persistent storage mechanism. If you
want to play with a sample set of modules to do this you may visit
http://www.extropia.com/ExtropiaObjects/
The SessionManager code hierarchy provides plug and play cookie, path info,
and hidden form variable session managers that wrap around a session
hierarchy (of which 90% is wrapped around Apache::Session as the persistent
storage mechanism).
SessionManager's belong in a different hierarchy than Session because you
don't want to couple the storage mechanism to the type of data... eg
Someone may want cookies with file based essions, another person might want
path info with database sessions, and yet another person might want a
cookie based session with database storage. etc...
I suspect it would not necessarily be too hard to write a subclass that
would attempt to check the cookie and if it did not exist, to use another
existing SessionManager to obtain the Session handle behind the scenes if
that is what you are referring to?
>The reason for asking is that other web technologies have this sort of
>functionality and this would be a great plus for mod_perl (I know it does
>not need it, and this can be easily writen..).
Agreed. Servlets for one support URL rewriting if cookies are turned off. I
don't think Microsoft ASPs support non-cookie based sessions, but I could
be wrong.
Later,
Gunther
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
