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?
Les Mikesell
[EMAIL PROTECTED]
