Ok, here's my super list of wanted session features.
Multiple reader, single writer locking. Or MVCC would be nice :) Otherwise if you use it for multiple requests at once(as in with ajax apps) everything slows way down. Having in the api a way to say 'I am just opening this for reading' would be really nice. Then backends that can implement this functionality can implement it. Backends that can't can implement locking however they want and ignore the read/write options passed. Performance, and locking for session objects is quite hard to get right if they are to be used by lots of different people, apps, and frameworks. Also having a specific close() method, rather than relying on garbage collection is important. Lazy opening of sessions is also good. So if it isn't touched then don't bother opening it. Support for cookie based, and url based sessions is also very important. It is also important to be able to chose which method you want to use. Security features like ip address, and referer checking can probably be implemented separately. As well as only allowing a user to get a session on one computer. These are optional things, but should be possible to do with whatever the session design is. Allowing a single browser to have multiple sessions open at once would also be good. This way you can avoid name clashes when mixing applications. Or for having separate session configurations for different parts of your application. Eg. database sessions for admin section, and memory based ones for your front end. Cheers. On 8/12/05, Shannon -jj Behrens <[EMAIL PROTECTED]> wrote: > Hey guys, > > Maybe I'm just ignorant (highly probable), but I'm really having a > hard time keeping up with the "configuration" emails, especially when > each of you is using slightly different definitions and trying to > reach slightly different goals. Please forgive me for coming out and > stating this. > > With the number of participants in the conversations, it doesn't seem > like we're making a huge amount of progress, although perhaps I should > shut up and be patient. > > In the meantime, I'd like to propose that we framework authors try to > start sharing our backend session code. Let's just create a library > like Apache::Session > <http://directory.fsf.org/webauth/misc/apache-session.html>. As much > as possible, I think we can make it framework agnostic, relying on the > framework itself to respond to callbacks for doing things like setting > session cookies and creating a database cursor. Just like with WSGI, > the frameworks need not change their external APIs. Let's keep it > simple and just make it a library. > > (I'm not sure the Twisted folks can participate because things on the > Twisted side are always so different, but hopefully I'm wrong.) > > In any case, it's just a proposal to try to share more code. If I can > get two other major frameworks to say they'll commit to working with > me and using/contributing to the library, I'll start the endeavor and > give them CVS commit rights. We need not write much new code. I'd > like to reuse code that each of us already has. This will have the > benefit of a lot of peer review. > > Perhaps this will make for a slightly better (Python Web) world :-D > > Best Regards, > -jj > > -- > I have decided to switch to Gmail, but messages to my Yahoo account will > still get through. > _______________________________________________ > 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/renesd%40gmail.com > _______________________________________________ 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