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

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.

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

Shannon -jj Behrens wrote: > ...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 > . > As much as possible, I think we can make it framework >

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

Shannon -jj Behrens wrote: > 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

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

If we get CherryPy (awesome, Robert!), Quixote, and Paste onboard, I'll consider it a huge success. -jj On 8/12/05, Ian Bicking <[EMAIL PROTECTED]> wrote: > Shannon -jj Behrens wrote: > > Maybe I'm just ignorant (highly probable), but I'm really having a > > hard time keeping up with the "configu

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

Ian Bicking wrote: >PythonWeb has a session >module, but I don't know what its insides look like: >http://www.pythonweb.org/projects/webmodules/doc/0.5.3/html_multipage/lib/session.html > I was going to suggest it might be worth looking at the PythonWeb web.session module as a basis. The versio

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

Ian Bicking wrote: > Paste has one too, but it's Not Very Good ;) I started using the flup session, but I got lazy and never flipped the switch to make it the default. There's been some discussion about sessions in the last few months on the Quixote list as well. session2 is at http://quixote.id

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

Op 12-aug-2005, om 23:08 heeft [EMAIL PROTECTED] het volgende geschreven: > If a Quixote application were installed in Paste and used a third- > party > session manager, the session object would have to: > - allow arbitary attributes. > - default .user to None. > - have a .set_user(user) me

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

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

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

-> I think that would be useful. Flup has a fairly decoupled session store -> (http://www.saddi.com/software/flup/ in -> http://svn.saddi.com/flup/trunk/flup/middleware/session.py). Is there -> other current work that should be considered? PythonWeb has a session -> module, but I don't know

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

Another session related wish: A few CherryPy users have requested[1] that there be an API for registering callbacks on sessions with the intent that those callbacks are invoked when a session is destroyed. Apparently this is something they are familiar with in the java servlet world. [1]ht

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

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! -jj On 8/14/05, Titus Brown <[EMAIL PROTECTED]> wrote: > -> I think that would be useful. Flup has a fairly de

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

I've also got reams of code in Zope for sessions. Maybe we should just wait til the next PyCon and have a consolidation sprint. - C On Mon, 2005-08-15 at 10:17 -0700, Shannon -jj Behrens wrote: > Heh, I'm overwhelmed by too much code and not enough direction. > Naturally, I've got nice session

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

-> I've also got reams of code in Zope for sessions. -> -> Maybe we should just wait til the next PyCon and have a consolidation -> sprint. -> -> On Mon, 2005-08-15 at 10:17 -0700, Shannon -jj Behrens wrote: -> > Heh, I'm overwhelmed by too much code and not enough direction. -> > Naturally, I'v

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

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 jus

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

The only thing I'm still concerned about is the locking. I lock access to the set of sessions when creating or deleting one, but I don't bother locking access to a single session. I think other people may have more strict requirements. I agree with Titus that we should stick to worrying about th

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

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

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

Robert Brewer wrote: > Quixote's session2 stores have flags for > multithreading/multiprocess but seem to not actually do anything with > those flags. Correct, the flags are just indications to the caller. The caller might raise an exception if a thread-unsafe store is paired with a multithreaded

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

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 consi

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

On Mon, 15 Aug 2005 15:46:19 -0500, "Ian Bicking" <[EMAIL PROTECTED]> said: > > 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 kn

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

Jonathan Ellis wrote: > On Mon, 15 Aug 2005 15:46:19 -0500, "Ian Bicking" <[EMAIL PROTECTED]> > said: > >>>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 su

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

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 prett

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

On Mon, 15 Aug 2005 15:57:55 -0500, "Ian Bicking" <[EMAIL PROTECTED]> said: > Jonathan Ellis wrote: > > On Mon, 15 Aug 2005 15:46:19 -0500, "Ian Bicking" <[EMAIL PROTECTED]> > >>In practice race conditions are very uncommon. Simultaneous requests > >>from the same session are uncommon, since what

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

Phillip J. Eby wrote: > 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 sess

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

At 05:08 PM 8/15/2005 -0500, Ian Bicking wrote: >Phillip J. Eby wrote: >>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 >>ar

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

Phillip J. Eby wrote: > 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. Yes, but the web-sig needs to define both APIs, and encourage generic implementations of both. Otherwise

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

Me: > 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

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

if I may throw my hat in the ring here, the session object I have built for Myghty accomplishes the following things, which were the important facets of a session for me: - it is neutral of its backend storage system. I developed a simple "storage" API that currently has DBM, memory and plain fil

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

On Tue, 16 Aug 2005 11:48:36 -0400 (EDT), "mike bayer" <[EMAIL PROTECTED]> said: > - because a "read" operation also registers a "last accessed time" data > member, its not using multiple reader/single writer style locking, > everyone is a writer. However, since I am sensitive to iframes, ajax > c

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

mike bayer wrote: > I mostly was using Apache::Session as a guide to the architectural > features I wanted to see, which include flexibility of containment and > locking systems as well as a separation between individual sessions. Is there a good API guide to Apache::Session somewhere? -- Ian Bi

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

mike bayer wrote: > - because a "read" operation also registers a "last accessed time" data > member, its not using multiple reader/single writer style locking, > everyone is a writer. However, since I am sensitive to iframes, ajax > calls, and dynamic image calls hitting the same session concurre

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

Ian Bicking wrote: > Though there's a couple issues. The sessino store should be passed > along with the session ID. It should be specified that loading a > session from this callback will not cancel its expiration. Maybe > per-session callbacks should be allowed; in which case the callbacks

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

> (And I'm also aware that "scaling down" is important, but the rule that all > state goes either in the browser or the application DB scales down just as > well as it scales up.) What's wrong with storing serialized session state in the database? -jj -- I have decided to switch to Gmail, but m

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

At 12:17 PM 8/17/2005 -0700, Shannon -jj Behrens wrote: > > (And I'm also aware that "scaling down" is important, but the rule that all > > state goes either in the browser or the application DB scales down just as > > well as it scales up.) > >What's wrong with storing serialized session state in

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

Phillip J. Eby said: > My point was that state either belongs to the client, or it > belongs to the *application* database. It's web-tier storage that forces > you to do session affinity when scaling the number of web servers, and to > deal with locking and other issues when scaling processes on

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

At 06:25 PM 8/17/2005 -0400, mike bayer wrote: >But even in this case, I think its a good idea to approach >per-user-session state information with code that is conceptually aware of >it being session-scoped information...meaning even if all my state is in >the database, id still want to access sta

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

Phillip J. Eby wrote: > You also mentioned prototyping, but a good object persistence toolkit > shouldn't be tied strictly to SQL; you ought to be able to plug in a > "pickle all the data to disk" mode and use it for *all* your > application data, not just the session-specific objects. And for

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

I checked with a bunch of "really smart people" who are familiar with a variety of Web technologies. I was worried that this idea "sessions are considered evil" was widespread, and I didn't know about it. Apparently, that is not the case. Phillip, I'm not discounting your opinion or even arguing

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

At 06:08 PM 8/17/2005 -0700, Shannon -jj Behrens wrote: >I checked with a bunch of "really smart people" who are familiar with >a variety of Web technologies. I was worried that this idea "sessions >are considered evil" was widespread, and I didn't know about it. Sadly, it's not widespread, any m

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

Phillip J. Eby wrote: > The reason it's How Things Are in Java-land is because Java made sessions > part of their servlet and other specs right from the start -- a serious > error that I was hoping we could avoid in Python-land. Too late; all the major (and even all the minor) Python web program

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

On Aug 17, 2005, at 6:49 PM, Phillip J. Eby wrote:That really hasn't been my experience.  Partly, this is because I tend to use RESTful approaches that put 99% of all statefulness in the browser.  For example, if I have a multi-page form, I embed all the previous pages' data as hidden fields on the

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

At 09:16 PM 8/17/2005 -0500, Ian Bicking wrote: >Phillip J. Eby wrote: >>The reason it's How Things Are in Java-land is because Java made sessions >>part of their servlet and other specs right from the start -- a serious >>error that I was hoping we could avoid in Python-land. > >Too late; all th

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

At 10:33 PM 8/17/2005 -0400, michael bayer wrote: >its usually not my experience either, and I have rarely written any kind >of app that uses sessions. 99% of everything I've done relies upon >browser state as well. although despite my being there "when the web was >won" in 95, I am hesitant t

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

Some more requirements for sessions can be found at the php page on sessions. Hash function declaring: Chosing eg md5/sha. Also by using a distributed hash function you can easily route the request to a specific web server. So with one rewrite rule you can have your scalable sessions/session

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

Phillip - I agree with you on all counts, except for the issue of how to determine when a session ends (timeouts, etc), and how to clean up the associated objects (Carts etc) with them. Peter Hunt ___ Web-SIG mailing list Web-SIG@python.org Web SIG: htt

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

Phillip J. Eby wrote: > I'm a pragmatic RESTee in that browsers don't do PUT > and DELETE, so POST is pretty much what we have to > work with for human-usable applications today. Unless you can rely on XmlHttpRequest, which supports arbitrary methods (which is why I made CP 2.1 fully support all H

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

On Thu, 2005-08-18 at 13:43 +1000, Rene Dudfield wrote: > ... and now for all the arguments pro Session rolled up into one paragraph. > > Taking load off the database server(with sessions) is a way to make an > application more scalable. In my experience, they can make applications less scalab

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

Rene Dudfield wrote: > Some more requirements for sessions can be found at the php page on sessions. > > Hash function declaring: >Chosing eg md5/sha. Also by using a distributed hash function you > can easily route the request to a specific web server. So with one > rewrite rule you can hav

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

At 12:03 AM 8/18/2005 -0400, Peter Hunt wrote: >Phillip - > >I agree with you on all counts, except for the issue of how to determine >when a session ends (timeouts, etc), and how to clean up the associated >objects (Carts etc) with them. I'm not sure I ever said how I clean up the associated ob

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

> What might be more practical and easier to think about because its scope > is so much smaller is a a common "browser identifier" implementation. > > The most useful purpose of a session is to allow you to store state > across requests by some anonymous browser. If you can reliably detect > that