[Web-SIG] Possible specs

[Phillip J. Eby]

At 07:45 PM 11/12/2006 -0800, Robert Brewer wrote:
>Sessions have 1) been around forever, 2) have consistently been done 
>similarly for each implementation, and 3) already require interoperation 
>with third party code (database APIs), so introducing a common interface 
>would not introduce any overhead. Therefore, session handling would be the 
>only candidate I see for standardization.

And even sessions are full of potential pitfalls for standardization, due 
to differences in things like authenticated vs. non-authenticated sessions, 
retention/expiration policies, and differing limitations on what can be stored.

Of course, there are also those persons like myself, who believe that the 
very concept of sessions as something apart from an application's domain 
model is the devil's work, doing harm to both the users and the 
enterprise.  ;-)  (E.g. ask yourself if Amazon.com uses anything that would 
be traditionally called a "session" database - their sessions are 
permanent, identified, and even an anonymous person's shopping cart items 
are retained for *90 days*.  And you can bet dollars to donuts that they 
can join "session" data to non-session data in their database queries.)

So, from my POV, having session bags where you can just dump whatever old 
data you please, without regard to the application's DB design (not to 
mention backup/uptime guarantees of the DB service), are things of the 
vilest evil that should be cast back into the bowels of Microsoft from 
whence they came, or something like that.  :)   (I first encountered 
sessions in MS's early ASP stuff, but perhaps they got the idea from 
somewhere else.)

Anyway, that's basically off-topic except to point out that even if you 
*are* a Satanis... er, sessionist, ;-), then you can still have 
wide-ranging disagreements over data retention policy, locking, etc., etc.