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. :) _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
