LK wrote:
Paul,
That looks like a lot of info to digest without specific examples. Is
there a book or other resource on session management that you
recommend that deals with these issues in more detail?
Thanks.
-Leo
I'm not aware of one, but I wish there was. I think the question
isn't so much "session management" but about how to manage state in a
stateless protocol -- sessions are one abstraction for doing that, but
other abstractions exist too.
I think the best approach here is the "Pattern Vocabulary"
approach. There are certain practices, that when applied to an
application, have certain results.
For instance, there's the pattern of "Stateless Server" -- the
complete state of the application (or subsystem thereof) is kept in
hidden POST and GET variables. You accept some limits, but get some
real benefits: infinite scalability, no headaches with the back
button, no need for cookies...
You might try the above and then notice that you're passing 100K
around in your hidden form variables... People are complaining that
your app is slow. Now you can generate a unique id each time you draw a
form ("Generated Form Scope", for lack of a better term.) You can
stuff your "hidden" variables into the database under this key, and
restore them when the key comes back... If your code is organized right
(does something like $vars=$_POST, and only looks at $vars
afterwards), you can do this transparently to the rest of your app.
The same kind of thinking can protect you against certain kinds of
back button woes -- you can at least stop people from submitting the
same form more than once, by checking to see if a form with that unique
id has been submitted before.
"Shopping Cart" is another pattern. People often use session
variables to handle shopping carts, but that's really not ideal from a
user interface perspective... Ideally, each instance of a shopping
cart has it's own unique id... Imagine we want to make an e-commerce
site that behaves like amazon.com:
(1) User visits e-commerce site from a home computer -- a long-term
tracking cookie gets stuck on their browser
(2) User adds item A to their shopping cart... A new shopping cart is
created with id #101, associated with the tracking cookie.
(3) User adds items B,C,D, and E to their shopping cart in the course of
30 minutes of browsing. Each time an item is added, we add a row to a
table in the database that links the item id to the shopping cart id.
(4) 4-year old hits reset button
(5) User comes back to e-commerce site... He's happy to find his cart is
still there. User creates account #202 to check out. Shopping cart
#101 is associated with account #202
(6) User checks out shopping cart.
(7) User comes back a week later, wants to buy a few more items. The
site recognizes who he is. He adds two of item A and an item F to a
newly created shopping cart with id #102, associated with user account
#202.
(8) User goes to work, logs in... The system sees that he has shopping
cart #102 open. He adds item G, and then checks out.
(9) User learns that he can trust this site to work correctly and
becomes a loyal customer.
It's nice that we've got a historical record of the shopping cart
after the fact, but there's a more important point -- we could have
lost the customer's dollar at many points in the above transaction if we
were using a $_SESSION based cart. The session wouldn't have survived
step 4, for instance. A good user interface isn't academic here... It
puts money in our pocket.
The above scenario is complex, and it might not be fair to expect
that a first-generation shopping cart has those features. A
$_SESSION-based shopping cart would need to be completely reworked to
add the features above. A cart that uses a unique "cart id" and
relational back end, will be a lot more maintainable... You could even
start out using $_SESSION to keep track of the "cart id", then keep it
in a cookie, then associate it with a user name, add the facility to
promote an anonymous cart to an authenticated cart and so on. Starting
with a good design, we can provide the interface that we ~want~ to
provide, not that one that our abstract layer ~forces~ us to provide.
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
