[Web-SIG] and now for something completely different!

[Phillip J. Eby]

At 06:25 PM 8/17/2005 -0400, mike bayer wrote:
>But even in this case, I think its a good idea to approach
>per-user-session state information with code that is conceptually aware of
>it being session-scoped information...meaning even if all my state is in
>the database, id still want to access state which is session-scoped via a
>"session" API.  having a strong concept of "session scope" makes it easier
>to model things like data caching for the right amount of time, user
>interface flow, creating multi-step transactions, etc.

That really hasn't been my experience.  Partly, this is because I tend to 
use RESTful approaches that put 99% of all statefulness in the 
browser.  For example, if I have a multi-page form, I embed all the 
previous pages' data as hidden fields on the subsequent pages.  The entire 
form is processed by a single validation routine, so it doesn't matter what 
the client sends or in what order, because as soon as all the data is both 
present and valid, the form is done.  Similarly, the vast majority of UI 
flow is easiest to model as URL-per-state, so that the browser is in charge 
of the flow, and the back button works.

As for caching, that's something that you tune when you have to tune it, 
for whatever you're tuning it for.  And that's on the basis of what type of 
object you're persisting.  Note that if you have a Cart type, let's say, 
then you don't really have a case where some Carts are session-specific and 
some are not!  Session-like behavior is inherent in the object types 
involved, so there's no real benefit to creating a secondary classification 
scheme for session scope.  The only session API I need in that case is:

     cart = get_cart(get_cart_id(request))

And since the cart is just another persistent application object, it's part 
of the same transaction, and I have nothing else to mess around with.

You also mentioned prototyping, but a good object persistence toolkit 
shouldn't be tied strictly to SQL; you ought to be able to plug in a 
"pickle all the data to disk" mode and use it for *all* your application 
data, not just the session-specific objects.