Ian Bicking wrote: > Shannon -jj Behrens wrote: > > Heh, I'm overwhelmed by too much code and not enough direction. > > Naturally, I've got nice session code in Aquarium as well. *Sigh* > > this Python Web thing is going to be the death of me! > > 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. The first critical implementation discussion (which affects the API) should be around concurrency, and if multiple locking strategies need to be supported. In flup, for example, the entire session store is locked if the same session is requested more than once simultaneously. Pythonweb doesn't seem to mention concurrency at all. Paste mentions it's not supported. ;) Quixote's session2 stores have flags for multithreading/multiprocess but seem to not actually do anything with those flags. The concern is not only response time, but atomicity. In the comments for Aquarium's SessionContainer: "Concerning locking: in general, a global lock (of some sort) should be used so that creating, deleting, reading, and writing sessions is serialized. However, it is not necessary to have a lock for each session. If a user wishes to use two browser windows at the same time, the last writer wins." That is a design decision which not all frameworks (or other consumers of our session lib) might share. Apparently, given the current Python session modules out there, it's common to survive without caring? I know Mike Robinson has worked many long nights trying to make a session module for CherryPy which can consistently pass simple hit-counter tests. ;) Personally, I'd like to pursue an MROW solution. It would be nice if our final product supported multiple concurrency strategies. The decision about which strategy to use could be left to framework authors (who would wish to begin migration by maintaining maximum backward-compatibility), or to their users, if those options can be described simply enough. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] _______________________________________________ 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