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

[Rene Dudfield]

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 <jjinux at gmail.com> 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 at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/renesd%40gmail.com
>