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

[Shannon -jj Behrens]

I checked with a bunch of "really smart people" who are familiar with
a variety of Web technologies.  I was worried that this idea "sessions
are considered evil" was widespread, and I didn't know about it. 
Apparently, that is not the case.  Phillip, I'm not discounting your
opinion or even arguing against it, but apparently, the entire world
didn't decide to start hating session scope behind my back ;)

/me giggles

-jj

On 8/17/05, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.
> 
> 


-- 
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.