|
Matthew D. Wood
woodm at equire.com
Wed Apr 18 00:10:12 EST 2001
I have to disagree. I think that mod-python (and mod_snake) handlers are perfect places to put session handlers. To me, the mod_python framework is somewhat equivelent to the PHP module only more flexable. PHP implemented sessions, and there is no reason why mod_python should be innapropriate for the task. It may be a bit difficult, but not impossible. If Apache 2.0 has some sort of shared memory, then obviously, this is a potential place. Other places certainly include cookies and databases. The clear advantage of the shared memory scenario is speed. This is definitely the case for a session.data_base_connection variable. You would have to access the data base way to many times just to do a simple query. I hate having to recreate database connections every page, and I don't like leaving one open all the time. I would much prefer to open it once for each user, then close it when things time out. I guess I don't understand why a session handler would be so bad. If the goal of mod_python is to give access, through a python interface, to the internals of apache in order to create pages or other environments, why can't we just treat sessions as a feature, or object that we create in a handler? I'm not suggesting that mod_python should come packaged with session capabilities built in. NO WAY! What I am saying is that a session handler, that somebody develops and posts on the mod_python page, could be available and tremendously usefull. I know that mod_snake comes packaged with 3 or 4 "typical" handlers that you can choose to use, or not. One is a python-cgi accelerator, one is an embedded python handler; why would a session handler not be appropriate? Then, the users could have a base session handler that they could modify as they see fit. If they want a more specific thing, specify. If you want a more general thing, either remove some code, or at worst, you have an example to work with. Just my opinions. Chris Hagner wrote: > On the issue of supporting modules (i.e. user sessions), there are simply > too many ways to implement something like that to make it worth coupling it > to mod_python. You'll either try to be too much for too many people (the > classic framework error) or you'll be so custom to your needs that your > audience is just you (not a bad thing, just not a place for a solution like > mod_python). > > I completely agree with Grisha that even the handler is outside of the core > mod_python functionality. That being said, a listing of available handlers > on the web site would be very useful for those starting/considering using > mod_python. I do think that having this area up there (even it's a bit > spares initially) will motivate others to share their handlers/frameworks > that are used with mod_python. > > What other handlers have people written? I've got one that implements a > servlet-like call mechanism (thereby avoiding the urls being mapped to > script files). It's not for everyone, but a perfect example of a decision > that was made for a specific need. > > Chris > > -----Original Message----- > From: Gregory (Grisha) Trubetskoy [mailto:grisha at modpython.org] > Sent: Tuesday, April 17, 2001 11:25 PM > To: Damjan > Cc: mod_python at modpython.org > Subject: Re: [mod_python] Persistent variable again... > > In my (humble) opinion, things like this are outside the scope of > mod_python, since the goal of mod_python is apache/python integration - > not building web application frameworks. In other words, mod_python is > something that makes Apache internals available in Python to give the > developer more power and speed, it's not something to make web application > development necessarily easier. > > There are a few of application frameworks out there that support > mod_python - webware is one of them. I don't know much about those things, > but I think they have features like state keeping, etc. > > (To that extent, even the mod_python.publisher handler is outside the > scope of mod_python, but I am willing to pursue it since it is immediately > usable, it serves as good test for advanced mod_python capabilities and > it's a pretty a good mod_python example program.) > > Ultimately, there should be an area on the website that lists mod_python > modules that do various things that aren't part of mod_python > distribution. Right now there aren't enough of them out there to justify > it, but eventually there will be I'm sure. > > So if you develop something that serves a particular need, please post it > to the list, and eventually we will have a collection of mod_python > modules/examples/whatever that people can use. > > Grisha > > On Wed, 18 Apr 2001, Damjan wrote: > > > > I'm trying to implement session like mechanism using mod_python. If > > > interpreter is created in each processes, is there a way to make a > > > variable really persistent? I think I should make some daemon that > > > connects thru named pipe to get/pass session information. Is there > > > any other way? > > > > I've been thinking about session managment for mod_python too, and it > seems > > like an important issue. I'd sugest we develop a common interface to > session > > managment, and then write specific modules that handle the job, by ways of > > cookies, databases, special daemons etc... > > > > Any ideas? > > > > -- > > Damjan Georgievski | Ð?Ð?мÑ~Ð?н > Ð?Ð?оÑ?гиÐ?Ð?Ñ?Ð?и > > Skopje, Macedonia | Ð?Ð?опÑ~Ð?, > Ð?Ð?Ð?Ð?Ð?ониÑ~Ð? > > _______________________________________________ > > Mod_python mailing list > > Mod_python at modpython.org > > http://www.modpython.org/mailman/listinfo/mod_python > > > > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://www.modpython.org/mailman/listinfo/mod_python > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://www.modpython.org/mailman/listinfo/mod_python
|