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

[Phillip J. Eby]

At 03:46 PM 8/15/2005 -0500, Ian Bicking wrote:
>Robert Brewer wrote:
> >>If everyone is reasonably comfortable with what sessions
> >>should do, can we just design an API and figure out the
> >>implementation later?
> >
> >
> > That depends on where you draw the line between the two. ;) It's pretty
> > easy to define an "implementation-less" API that consists of: create,
> > read, update, delete.
>
>Yes, but we're all clever enough to know that's incomplete ;)

Personally, I think the most important part of session services is just 
managing the session itself; start, begin, timeout, and getting an 
identifier in and out of the request/response.  For me, 
create/read/update/delete/persist/GC responsibility belongs entirely to the 
application.  To put it another way: I don't believe in session variables, 
only session-specific application objects.  An ecommerce application should 
have persistent carts and items and the like; the only purpose of a session 
is to find out which cart to look at.

In this way, concurrency and all the other questions being raised here are 
irrelevant.  Or at least they're irrelevant to the session management part, 
anyway.  :)

So I'd personally prefer that any session service standards distinguish 
between management of the session itself, from storage of data associated 
with the session.  The latter is just a standard object-persistence or 
object-relational problem and can easily be dealt with as such, distinct 
from session management issues like cookies vs. URLs, timeouts, ID 
generation, and so forth.  (Note that even GC of abandoned sessions is 
highly subject to business rules, and it would be crazy for us to try and 
encompass the possible rule variations within a relatively simple component 
specification.)

While it may be nice to have persistence services that are optimized for 
session-like use cases, it doesn't make a lot of sense to tightly couple 
them to session management.  Just like WSGI splits things into application 
and server, I think a session spec should split them into 
client-state-management and server-state-storage, so that we can mix and 
match from the best of both worlds.

Of course, I personally prefer to use whatever the application's storage is 
for my session management, so I'll probably have little reason to get 
involved in the "storage" side of the session equation.  Indeed, I'd argue 
that applications that *don't* put their session data in the application's 
main DB should have very very good reasons for doing so, and I've never 
heard a good enough reason yet.  :)  Well, there's, "my application's DB 
suxors", but that means you ought to upgrade the application DB instead if 
you can.  :)