Re: [jira] Commented: (MODPYTHON-55) Add a version attribute to the mod_python module.

2005-05-20 Thread Jim Gallacher
Nicolas Lehuen wrote:
It has not much impact since I simply don't use configure, nor make.
To build under Windows XP, I just launch the  Python script in
dist\setup.py.in .
Note the .in extension, which seems to mean that it should have been
transformed by another script. However, when having a look at the
script, I do not see any @@ macro. So I guess it's safe for it to be
launched as is.
The macro processing done by configure looks for any file ending in .in, 
makes the macro substitutions (anything enclosed by @@) and creates a 
new file with the .in extension stripped off.

In fact it seems that we could solve all our versioning issues by
tweaking this setup.py.in script.
Looking at setup.py, there is already a function (getmp_version) which 
parses mpversion.h, so we're half way there. Just need to add another 
function to do dump the version string into __init__.py.

Probably worth waiting for the patches from David Fraser though. See: 
http://issues.apache.org/jira/browse/MODPYTHON-55?page=comments#action_65861

Jim
Regards,
Nicolas
2005/5/20, Jim Gallacher [EMAIL PROTECTED]:
Nicolas Lehuen wrote:
The problem is that this won't work when building on Windows. I think
we should use Python scripts instead of configure, grep et al which
are not truly portable (well, I hear you, portable everywhere except
on Windows :)).
Use python? PYTHON   Well, the very idea... :)
Same principal, different tool. I'd still be willing to take a shot at it.
Just curious - how does the use of awk and sed in configure impact
building on Windows?
Regards,
Jim

2005/5/20, Jim Gallacher (JIRA) [EMAIL PROTECTED]:

   [ 
http://issues.apache.org/jira/browse/MODPYTHON-55?page=comments#action_65861 ]
Jim Gallacher commented on MODPYTHON-55:

Would it be appropriate to determine the version at configure time?
If so we could create a file mod_python/__init__.py.in which would contain:
version=@MP_VERSION@
and configure would grep src/include/mpversion.h for MPV_STRING and generate 
__init__.py from __init__.py.in.
If this seems reasonable I can put something together.

Add a version attribute to the mod_python module.
-
   Key: MODPYTHON-55
   URL: http://issues.apache.org/jira/browse/MODPYTHON-55
   Project: mod_python
  Type: Improvement
  Versions: 3.1.4
  Reporter: Nicolas Lehuen
  Assignee: Nicolas Lehuen
   Fix For: 3.2.0

(asked by dharana) There is no easy way to know the version of mod_python used from within an handler. Why not try to add a version string attribute to the mod_python module ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
 http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
 http://www.atlassian.com/software/jira





Re: _apache.emergency_unlock function?

2005-05-20 Thread dharana
I don't know if it's related but I'm having some troubles with the current 
FileSession implementation. It causes a segfault when I do this:

- login creating a session and go to any page
(spend enought time looking down until session expires)
- f5 at the browser
apache segfaults and the only way to enter again is to manually delete the pysid 
cookie.

I will try to find the root of the problem. It happened to me some weeks ago but 
I incorrectly thought it was caused by something else.

Nicolas Lehuen wrote:
Why not, but I really think that we should find a simple way to solve
the problems created by building multiple sessions or multiple
FieldStorage instances on the same request.
In the Java (i.e. servlets) world, when you want a session, you just
ask for it on the HttpRequest object. If a session exist, you get it,
if not, it is created. If you never ask for a session, then it is not
created, this way a session is not mandatory for pages which do not
require it.
I really think the current way of building Session instances in
mod_python is weird. First, because it opens a whole bunch of bugs due
to multiple Session instantiation (i.e. deadlocks). Second, because
the Session hosting infrastructure is up to the developer (which can
choose between MemorySession, DBMSession or FileSession) whereas I
think it should be up to the hoster.
The session infrastructure should be defined in httpd.conf or a
.htaccess file, with something like :
PythonOption SessionInstantiation FileSession(directory='/tmp/sessions')
Then, there would be a get_session() method on the request object,
that would check if a session is already present and if not would
execute the code defined in SessionInstantiation.
Something similar should be done with the form parsing mechanism.
Instantiating FieldStorage should be done my mod_python, not the
developer. The developer could then call req.get_uri_parameters() (all
the function names are of course subject to debate) to get the
parameters that were passed in the URI, req.get_form_parameters() to
get the parameters that were passed in a POST of content type
application/x-www-form-urlencoded, and req.get_combined_parameters()
for a combination of the two sets of parameters. Trying to read on the
request after a call to get_form_parameters() should raise an
exception, and conversely.
Solving these two problems would simplify a lot of code and could
please a lot of people, except from the fact that this would break
some compatibility with previous code :(.
I know there is a lot of shouldas and wouldas in this mail but I
really feel that some people who are used to other web frameworks can
be horrified by some very low level issues that they have to solve by
themselves. Other web frameworks are a little more helpful. Do we
really want developers to loose time thinking about whether the number
of times they already instantiated a Session object ?
Regards,
Nicolas
--
dharana