Just so that many of you do not wonder We are a TLP - where is it???
Everything is well. :)
It's just turned out that selecting python.apache.org as the main
destination for it is not something that everyone is in agreement on and
quite a bit of discussion had to take place, and we're still
. ;)
I'm not a fan of pypache for the same reasons that others have stated.
Projects that stick py, q, k or gnu on the front of the name have always
bugged me.
Jim
Gregory (Grisha) Trubetskoy wrote:
So far PyPache seems to be the winner. Terranium is second, Quetzalcoatl
thrid.
Let's say
On Sun, 20 May 2007, Justin Erenkrantz wrote:
FWIW, the full name of the TLP will be: Apache foo - so Apache
PyPache doesn't roll off the tongue very well...
Yes, Apache PyPache does sound a bit silly. My vote is then:
+1 Quetzalcoatl
Those who have not voted yet (there are hundreds of
So far PyPache seems to be the winner. Terranium is second, Quetzalcoatl
thrid.
Let's say this vote closes on Wednesday, and please send in +1's for one
name - statements like I like both blank and blank are hard to
account for.
On Fri, 18 May 2007, Clodoaldo wrote:
+1 pypache
I like Quetzalcoatl and PyPache. Terrarium seemed nice at first, but then
the ophidiophobia in me took over. (Nobody suggested ophis, btw..)
On Wed, 16 May 2007, Gregory (Grisha) Trubetskoy wrote:
So I think we've got (in no particular order):
PythonScript
Pythonidae
PyPache
pythonalia
So I think we've got (in no particular order):
PythonScript
Pythonidae
PyPache
pythonalia
Quetzalcoatl
Asphyxia
Scales
Pythonistas
PigeonPy
Pungi
Would people (ANYONE here on the list, yes, that includes *YOU*) please
respond with the one they like most and I will compile the results?
I just got back from Nicolas's country where my 'net access was a bit
spotty, but everything else was great (but expensive) as always... :-)
core +1 from me
as soon as i get over the jetlag and catch up with things, i'll do the
rest (we have all the core votes, right?)
grisha
On Thu, 1
The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.3.0b (Beta) release of mod_python.
Version 3.3.0b of mod_python features several new functions and
attributes providing better access to apache internals, as well as
many bug fixes and various
mod_python team.
On Fri, 15 Dec 2006, Jim Gallacher wrote:
Gregory (Grisha) Trubetskoy wrote:
I concur - my +1 was for a beta
+1 for 3.3.0 beta
Jim
grisha
On Wed, 13 Dec 2006, David Fraser wrote:
I'm not core but I think its good practice to officially release this
as a beta
Gallacher wrote:
Gregory (Grisha) Trubetskoy wrote:
core +1 on releasing it into the wild
grisha
I'm not sure what we're voting on here, and I'm not sure what I meant by
the next level either. :)
Is this a vote to give 3.3.0 beta a wider release (apache mirrors and so
on), or a vote to go
core +1 on releasing it into the wild
grisha
On Mon, 11 Dec 2006, Jim Gallacher wrote:
Test results so far, FYI. How long shall we wait until we kick it up to the
next level?
- jim
+1 FreeBSD 6.1, Apache 2.2.3 (mpm-prefork), Python 2.4.3,1
+1 Linux Debian 3.1 Sarge, Apache 2.0.54
The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.2.10 release of mod_python. Mod_python
3.2.10 is considered a stable release, suitable for production use.
Mod_python is an Apache HTTP Server module that embeds the Python
language interpreter
The site's been update (both mopython.org and the download page), so
3.2.10 is out. I'll work on the announcement next.
Grisha
On Mon, 31 Jul 2006, Gregory (Grisha) Trubetskoy wrote:
Core +1 from me. I will take care of the signing, etc, some time tomorrow.
P.S. In order for you
Core +1 from me. I will take care of the signing, etc, some time tomorrow.
P.S. In order for you to be able to sign you need to meet in person
someone (or probably more than one person) from ASF. ApacheCon is the best
place, and members do not have to pay the conference fee (at least I think
cleanups failing and why is covered by:
http://issues.apache.org/jira/browse/MODPYTHON-109
The last test results were submitted July 1, so I think we may as well
have a core vote.
Jim
Gregory (Grisha) Trubetskoy wrote:
I'm barely keeping my head above water right now with work, so
I'm +1 on going for 3.2.10.
You in Canada probably have it easier - I think we hit 96F/35C at some
point today or yesterday (I wouldn't know I'm in the office which has AC
sunrise to sunset, I just listen to the news), and unfortunately (or not)
due to work pressures I have no time for
On Tue, 18 Jul 2006, Jim Gallacher wrote:
For 3.2.9 I called for 2 rounds of testing: one for the release
candidate and one for the final tarball. Do folks here feel that is
necessary for 3.2.10 or should I just jump right to the 3.2.10 final?
That tarball would still be subject to a vote on
This was sent to me directly, anyone willing to act on it? (I don't have
the CPU cycles right now).
-- Forwarded message --
Date: Mon, 17 Jul 2006 18:12:07 +0200
To: [EMAIL PROTECTED]
Subject: new mod_python faq
I think may be useful to add this question:
2.30. Why do I get
On Sun, 26 Mar 2006, Graham Dumpleton wrote:
One use for it that I already have is to get around the DirectoryIndex
problems in mod_python caused by Apache's use of the
ap_internal_fast_redirect() function to implement that feature. The
specifics of this particular issue are documented
I'm -1 on updating req.finfo when req.filename is updated. I don't have
the time to explain it in detail, but I think it flows from Graham's
explanation below.
Basically, httpd does a stat() for you, and its result is stored in finfo.
Why make it any more complicated and magical?
If you
Could folks with access to different OS's try the following:
Compare output of apxs -q CPPFLAGS with the value of _FILE_OFFSET_BITS
in pyconfig.h.
For example, on my Fedora Core 4 i386 system (stock httpd and python):
$ /usr/sbin/apxs -q CPPFLAGS
-DSSL_EXPERIMENTAL_ENGINE
[note - no
On Mon, 13 Mar 2006, Graham Dumpleton wrote:
Thus I want a documented convention that if a handler is going to use
util.FieldStorage, that it should before doing so, first check whether
an existing instance resides as req.form and use that instead.
I'm not sure if this is a good example -
On Mon, 13 Mar 2006, Jim Gallacher wrote:
The idea of something like req.get_session() is to give users an obvious way
to grab a session object without the deadlock concerns. How many times have
we seen this kind of problem-code on the mailing list?
def index(req):
sess =
I'm -1 on get_session() too. The request object is supposed to be a
representation of Apache's request, and get_session() just does not belong
there.
Grisha
On Sun, 12 Mar 2006, Jim Gallacher wrote:
I handn't really intended to start working on an implementation. I just don't
like seeing
I don't understand this enough to have an opinion on it, seems like
another way to skin a cat, but to really form an opinion would require
some thinking on my part at least (may be I'm getting thick with age).
I think it'd be great if those who send in +1's (or -1's) would explain
why they
The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the release of version 3.2.8 of mod_python.
This release addresses a vulnerability in mod_python's FileSession
object whereby a carefully crafted session cookie could potentially
permit an attacker to
If you see any problems with this text, let me know.
-- Forwarded message --
Date: Sat, 12 Feb 2005 22:00:56 -0500 (EST)
From: Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]
To: announce@httpd.apache.org, [EMAIL PROTECTED]
Cc: python-dev@httpd.apache.org
Subject: [ANNOUNCE
end up serving the files from my
personal hosting solution, which is not really tailored for that.
You can find the binaries here :
http://nicolas.lehuen.com/download/mod_python
TIA and regards,
Nicolas
2006/2/21, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]:
Resolved, the files have been
If I understand this correctly, then +1.
...though I'm wondering if anyone will actually try to do something as
arcane as dynamicaly registering non-content handers? :-)
Grisha
On Tue, 21 Feb 2006, Jim Gallacher wrote:
Nice summary.
+1 for the change.
Jim
Graham Dumpleton wrote:
Jim
If you are using the recently released mod_python 3.2.7 please beware that a
security issue was discovered in the FileSession code.
You are vulnerable only if you are using mod_python 3.2.7 AND you are using
FileSession to keep sessions. FileSession is new in 3.2.7 and is not enabled by
On Tue, 14 Feb 2006, Jim Gallacher wrote:
I wonder if we should generalize this, so rather than PythonMutexDir, we have
PythonModuleConfig. Usage might look like:
PythonModuleConfig mutex_dir /path/to/mutexs
PythonModuleConfig max_mutex_locks 8
I may be wrong, but I think the reason this
On Tue, 14 Feb 2006, Nicolas Lehuen wrote:
2006/2/14, Graham Dumpleton [EMAIL PROTECTED]:
[...]
If we want to go down the path of having interim 3.2 bug rollup releases
while 3.3 is being developed, might I suggest that we target the following
for such a release in the near future.
The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.2.7 release of mod_python. Mod_python 3.2.7
is considered a stable release, suitable for production use.
Mod_python is an Apache HTTP Server module that embeds the Python
language interpreter within
On Thu, 9 Feb 2006, Jim Gallacher wrote:
Depending on Grisha's preference, I think we should either put the
content in svn and have a cron job on modpython.org do a nightly update,
or start using the Apache infrastructure for the website. See
http://www.apache.org/dev/project-site.html for
On Thu, 9 Feb 2006, Jim Gallacher wrote:
Looks good. As soon as you make the official announcement I'll create
branches/3.2.x in svn and we can start on 3.3.
I don't think we need to wait for the announcement - 3.2.7 is already out
if you look on the download page, the announcement is more
On Tue, 7 Feb 2006, Jim Gallacher wrote:
I assumed we would have a separate thread for the core vote, but what the
heck. :)
+1 is my core vote.
+1 from me as well.
Grisha
On Tue, 31 Jan 2006, Jim Gallacher wrote:
I assume we will be doing a 3.2.7 release if Graham's fix for the
ConnectionHandler / MODPYTHON-102 problem works?
Unfortunately, the answer is yes... As much as we'd like to release it
sooner, I think it's important to not loose the perspective
This may be a good question to post to dev@httpd.apache.org
Grisha
On Mon, 30 Jan 2006, Graham Dumpleton wrote:
Getting a bit closer now, have next part of puzzle worked out.
Graham Dumpleton wrote ..
This is starting to look really ugly.
In _conn_read(), it first creates a bucket brigade
On Sun, 29 Jan 2006, Graham Dumpleton wrote:
Grisha wrote ..
buffer = bufsize;
I suspect you mean't:
buffer += bufsize;
buffer = bufsize should be correct because you move the pointer to the end
of where the bufer was. buffer += bufsize would set it further
On Sun, 29 Jan 2006, Graham Dumpleton wrote:
buffer += bufsize;
On a second thought - yes, you're right :-)
Grisha
On Thu, 26 Jan 2006, Jim Gallacher wrote:
It seems like any 3.2.6 testing that is going to be done, has been done.
I've been kinda swamped with unrelated things past two weeks, so I wasn't
paying much attention. Perhaps an e-mail summarizing the +1's so far and a
quick vote of the core
On Thu, 19 Jan 2006, Jorey Bump wrote:
+1 here, but since the build process and typical MPM differs among platforms,
could we see a list that this group represents?
This group would not represent any platforms when acting in _this_
capacity. One of the group's responsibility would be to
On Mon, 2 Jan 2006, Graham Dumpleton (JIRA) wrote:
Should this be fixed in 3.2, given that it probably hasn't work in 3.0 and 3.1?
I think it would be a good idea. Hopefully this is the last fix before we
roll it out.
Grisha
On Mon, 2 Jan 2006, Graham Dumpleton (JIRA) wrote:
In addressing MODPYTHON-71, mod_python.publisher code was changed to read:
if req.method!='HEAD':
req.write(result)
This change should not really have been made and it should be changed
back to what was there before, ie.,
On Wed, 4 Jan 2006, Gregory (Grisha) Trubetskoy wrote:
It may be a good idea to check the httpd-dev archives to see if the
issue of HEAD has been discussed in the past.
Here's a relevant bit of info from the httpd-dev archives:
* All handlers should always send content down even if r
On Wed, 4 Jan 2006, Graham Dumpleton wrote:
Either way, we agree that mod_python.publisher should still output
content for HEAD.
Yep.
I would also propose as a change that the req.write() call not cause
output to be flushed to allow an output filter like CONTENT_LENGTH
to be used.
On Wed, 4 Jan 2006, Graham Dumpleton (JIRA) wrote:
This makes one wander if there should be a configurable option for
mod_python.psp to tell it not to flush output as well so that
CONTENT_LENGTH could be used in that case as well. ???
I kinda mentioned this in the previous e-mail - PSP
I hope everyone's having a merry Christmas or whatever other holidays
you're celebrating :-)
I haven't been following the list very closely lately, but it looks like
last time 3.2.6b was brought up a bunch of bugs came out of the woodwork.
Does it look like we're near being ready to roll
On Tue, 20 Dec 2005, Graham Dumpleton wrote:
Grisha, do you remember why the following warning is present in
directive_PythonInputFilter() and directive_PythonOutputFilter() of
mod_python.c.
/* register the filter NOTE - this only works so long as the
directive is only allowed in the
On Wed, 21 Dec 2005, Graham Dumpleton wrote:
/* register the filter NOTE - this only works so long as the
directive is only allowed in the main config. For .htaccess we
would have to make sure not to duplicate this */
Having input/output filters be able to be specified in
This sounds like a good idea, but it's probably better to push this off to
3.3 just to veer on the side of caution.
My $0.02
Grisha
On Tue, 20 Dec 2005, Graham Dumpleton wrote:
Anyone know if there are any technical reasons why input/output filters
as they exist at the moment, applying
On Fri, 9 Dec 2005, Jim Gallacher wrote:
Next question. Should we bump the Apache version requirement as well.
Currently the docs state that Apache 2.0.40 or later is required. I
don't recall seeing anyone testing mod_python 3.2 on anything less than
apache 2.0.53. I don't know if there are
On Sat, 3 Dec 2005, Nicolas Lehuen wrote:
2. I don't know - I did not made this to distribute
It's a _very_ nice document, but I think you jumped the gun by checking it
into Doc because it's not a .tex file and doesn't fit into the Mod_python
manual, which is what the Doc directory is for.
On Tue, 29 Nov 2005, Nicolas Lehuen wrote:
def current_url(req):
[snip]
# host
current_url.append(req.hostname)
[snip]
This part isn't going to work reliably if you are not using virtual hosts
and just bind to an IP number. Deciphering the URL is an impossible task -
I used to
On Tue, 29 Nov 2005, Jim Gallacher wrote:
I still think the correct place to create the index dictionary is in the
__init__ phase. Using the dictionary-on-demand idea only improves performance
on the second access to a form field. For the first access you are still
iterating through the
I don't know how to do that, and it doesn't bother me that much :-)
Grisha
On Mon, 28 Nov 2005, David Fraser wrote:
Gregory (Grisha) Trubetskoy wrote:
The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the 3.2.5 Beta release mod_python.
Can we make
On Thu, 17 Nov 2005, Jim Gallacher wrote:
Gregory (Grisha) Trubetskoy wrote:
OK, I think we got enough +1's and no show-stopping problems (for a beta
at least). I copied it over the apache server, once the mirrors sync I'll
update the site and send the big announcement.
I was also
OK, I think we got enough +1's and no show-stopping problems (for a beta
at least). I copied it over the apache server, once the mirrors sync I'll
update the site and send the big announcement.
Grisha
On Mon, 14 Nov 2005, Jim Gallacher wrote:
A new mod_python 3.2.5 beta tarball is now
hehe - sorry about that, should be fixed now
Grisha
On Tue, 15 Nov 2005, David Fraser wrote:
Jim Gallacher wrote:
A new mod_python 3.2.5 beta tarball is now available for testing. A
windows binary should be available shortly.
The windows binary for python 2.3 is borked, and contains its
On the mod_python side we got a 3.2.2 beta out and will try to get 3.2.?
final done before Apachecon (hopefully). The last release (not counting
security fix ones) was 20 months ago, so this is pretty significant.
Grisha
On Mon, 14 Nov 2005, Roy T. Fielding wrote:
Much to my surprise, I
On Thu, 3 Nov 2005, Graham Dumpleton wrote:
With the thought of mod_python perhaps ignoring the PythonEnabledPdb
option when not run in single process mode, is there a way using the
apache.mpm_query() function or some other function of determining that
Apache is running in single process mode?
If we don't get an resolution on this Gentoo issue - should we just go
ahead and release the file anyway? Hopefully then someone will fix it
before the final release?
Grisha
On Tue, 25 Oct 2005, Gregory (Grisha) Trubetskoy wrote:
Hmmm... Looking at /usr/lib/python2.4/httplib.py
,
then submit it to the list for test/vote for public release.
Grisha
On Thu, 27 Oct 2005, Jim Gallacher wrote:
Gregory (Grisha) Trubetskoy wrote:
If we don't get an resolution on this Gentoo issue - should we just go
ahead and release the file anyway? Hopefully then someone will fix it
before
On Sat, 22 Oct 2005, Jim Gallacher wrote:
Just a note on updating src/include/mpversion.h. Should we be changing
MPV_PATCH in svn trunk (and by extension MPV_STRING) to track the beta
release patch level? In trunk we are still at MPV_PATCH 0, but in
tags/release-3-2-2b we are at MPV_PATCH 2.
On Fri, 21 Oct 2005, Nicolas Lehuen wrote:
Hi,
http://issues.apache.org/jira/browse/MODPYTHON-82 is resolved and fixed in
trunk. Are you sure you didn't interchange the two issues ?
Cool, I'm reading my mail serially.
Grisha
On Fri, 30 Sep 2005, Graham Dumpleton wrote:
BTW, what is the timetable for actual release of 3.2? Where I
am working is finally upgrading to Apache 2.0 on one of their
servers and want to be able to use final 3.2 release on the
system.
I think we should give a few weeks to give people a
Can we have a little discussion on pros/cons of this? Does this make
mod_python dependent on sqlite?
Thanks,
Grisha
On Tue, 20 Sep 2005 [EMAIL PROTECTED] wrote:
Author: nlehuen
Date: Tue Sep 20 14:28:32 2005
New Revision: 290569
URL: http://svn.apache.org/viewcvs?rev=290569view=rev
Log:
OK, my next question would be - is MySQL, PostgreSQL, Informix, Oracle,
etc next, and is this the path we want to take, or is there something
about sqlite that makes it unique?
Grisha
On Thu, 22 Sep 2005, Robert Sanderson wrote:
Can we have a little discussion on pros/cons of this?
We should give it a couple of days to make sure that no -1's appear. Once
we have a good number of +1's and sufficient time has passed to be
reasonably sure that no -1's are coming, the file will need to placed on
www.apache.org, PGP-signed, given about 24 hours for mirrors to pick it
up;
Jim
Gregory (Grisha) Trubetskoy wrote:
Here's a patch (this is against 3.1.2b). Untested. This replaces
GIL
with with the APR lock.
--- src/mod_python.c.orig Mon Sep 12 16:42:28 2005
+++ src/mod_python.cMon Sep 12 17:32:26 2005
is getting logged in test/logs/error_log:
[Mon Sep 12 19:49:33 2005] [emerg] (2)No such file or directory: Couldn't
create accept lock
Jim
Gregory (Grisha) Trubetskoy wrote:
Here's a patch (this is against 3.1.2b). Untested. This replaces GIL with
with the APR lock.
--- src/mod_python.c.orig
it and I'll add a test to remove it
when running the test on Win32.
Regards,
Nicolas
2005/9/13, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]:
OK, I found the problem. The LockFile line is commented out in test.py
which causes Apache to try to create the lock in the default location in
/var/run
don't know why though... I'll have to review the code once
more to understand.
Regards,
Nicolas
2005/9/13, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]:
Good job - I've tested it and it works on FreeBSD. Just one last thing I
wanted to confirm - are you sure that PyEval_AcquireLock is required
you - isn't this asking for a segfault/deadlock/whatever?
Grisha
On Mon, 12 Sep 2005, Jim Gallacher wrote:
Gregory (Grisha) Trubetskoy wrote:
Shouldn't that be PYTHON_WITH_THREAD rather than MOD_PYTHON_WITH_THREAD?
I understand it to mean that we want the thread handling code compiled
On Thu, 8 Sep 2005, Jim Gallacher wrote:
I don't have FreeBSD, or any experience with any BSD, but I won't let that
stop me from commenting. :)
I don't see apr-0 listed in your includes in the above output.
APR_THREAD_MUTEX_UNNESTED is defined in apr_thread_mutex.h, which on debian
is in
On Wed, 7 Sep 2005, Jorey Bump wrote:
-1
Slackware Linux 10.1
Python 2.4.1
Apache 2.1.6 Alpha
I don't think we mean to support 2.1.6 alpha, so this doesn't count. :-)
Grisha
Anybody got FreeBSD? I'm getting this. This is an old and possibly
misconfigured system, so the problem could be on my end.
FreeBSD 4.9
apache 2.0.53 (from ports)
python 2.3.3
$ make
Compiling for DSO.
/usr/local/sbin/apxs -I/home/grisha/src/tmp/mod_python-3.2.1b/src/include
I've been away this weekend - just got back, but I'm too busy to try to
read all the multiple-interpreter related comments. I guess my question is
- can someone provide a quick summary of how far we are from 3.2.1b test
tarbal?
Thanks!
Grisha
On Thu, 1 Sep 2005, Graham Dumpleton wrote:
On Tue, 6 Sep 2005, Jim Gallacher wrote:
As Graham stated on the weekend, the use of thread states can be very
tricky. I think we should proceed with the 3.2.1b without the fix. That way
we can take the time to make sure we understand the issues and fix it in 3.3.
If that seems reasonable,
', 'mod_python')},
scripts=scripts,
data_files=data_files,
- ext_modules=[ModPyModule, PSPModule])
+ ext_modules=ext_modules)
# makes emacs go into python mode
### Local Variables:
On Thu, 1 Sep 2005, Gregory (Grisha) Trubetskoy wrote:
On Wed, 31 Aug 2005, Jim Gallacher
On Thu, 25 Aug 2005, Jim Gallacher wrote:
I think we should aim for the second beta release in the next couple of days.
I have a few questions and a list of outstanding issues.
Name of tarball: mod_python-3.2.1b.tgz?
yep, 3.2.1b
Also, I assume a new branch called tags/release-3.2.1-BETA
On Fri, 26 Aug 2005, Nick wrote:
Here's another idea: Fail the flex test fairly silently (e.g. just no), but
fall back to a script that generates a nice, verbose error message explaining
the situation. That way, when the user tries to call make after modifying
the .l file, the fake flex
On Tue, 16 Aug 2005, Jim Gallacher wrote:
What is the correct name for the tarball?
mod_python-3.2.0-b.tgz, mod_python-3.2.0-BETA.tgz or something else?
I like mod_python-3.2.0b and the tarball would be mod_python-3.2.0b.tgz
Grisha
I think the best thing to do is just to go ahead and tag and a create a
tarball. Whether everyone was ready will become apparent during the
testing/voting.
Grisha
On Mon, 15 Aug 2005, Jim Gallacher wrote:
Are we on track to release a 3.2.0beta tarball today?
Regards,
Jim
On Tue, 9 Aug 2005, Jim Gallacher wrote:
My question is : should we keep on with ./configure ; make ; make install
or try to do everything in setup.py ?
As long as we can put setup.py in a Makefile. ;)
Seriously though, ./configure --help; ./configure; make; make install; is
just such
On Mon, 8 Aug 2005, Jim Gallacher wrote:
I had to double escape the r, ie \\\release to make it work. Grisha, did
you generate the docs on BSD before, and if so is the BSD sed different?
Yes, it was always done on FreeBSD before - it is quite likely that the
sed is different More likely
Just thought I'd ask if we're making any progress towards a 3.2 tarball to
test. No pressure, just curious :-)
Grisha
Yeah, we've got to be inline with the HTTP Project - prefork is the
default on unix systems, so we have to abide by it...
So I guess the solution is that we need to reserve two locks instead of
just one?
Grisha
On Thu, 23 Jun 2005, Jim Gallacher wrote:
Nicolas Lehuen wrote:
Hi Jim,
On Fri, 17 Jun 2005, Nicolas Lehuen wrote:
As for the MySQL implementation
I'd stay away from anything vendor-specific in mod_python, because then
the question becomes why not a postresql, why not oracle, etc.
Grisha
Hi folks -
We have a new committer - Jim Gallacher. Thanks Jim for all your
contributions to mod_python and for accepting the invitation to become a
committer!
Cheers,
Grisha
90 matches
Mail list logo
