On 17/04/2006, at 6:43 PM, Nick Kew wrote:
On Monday 17 April 2006 07:45, Graham Dumpleton wrote:
On 17/04/2006, at 4:27 PM, Nick Kew wrote:
On Monday 17 April 2006 07:13, Ian Holsman wrote:
OK, let's play ...
- Language bindings (mod_[perl|python|etc]) for new goodies
like DBD and XMLNS
This possibly ties up with something which I was intending to one day
implement
in mod_python. That is to export from mod_python, as optional
functions, functions
which would allow one to get access to the Python interpreter
instances plus other
functions for accessing/creating Python wrappers for request, server
and filter
objects.
The original intent of doing this was so that module writers using C
code could
access the Python interpreters already managed by mod_python and then
provide a means in their own module of being able to use Python code.
We actually have an analagous setup working with Tcl. It's quite a
small
module, but works well to run Tcl script embedded in HTML pages, and
help the Client upgrade from the vignette system they previously used.
A separate module - used by the interpreter - provides Tcl bindings
for DBD.
My thought on doing the same with Python is that it really
shouldn't need
the full baggage of mod_python just to do this. All they really
have in
common is the python interpretors. So maybe the architecture for this
could look something like:
mod_python_base (manage the python interpreters)
mod_python (as now, less what's moved to python_base) - big
mod_python_embedded (python interpreters for C programmers) - small
There isn't actually much in mod_python that could be extracted out
into a
base or embedded package. Pretty well all the C code would still be
required in order to support the basic stuff that would be exportable as
optional functions. The only bits that might not move are code for
filter and
handler directives for registering and then invoking handlers as part of
normal Apache request processing phases. This would be at most a few
hundred lines of code.
In terms of the package as a whole and what possibly shouldn't be in
mod_python are the mod_python.publisher and mod_python.psp handlers
which are in effect a layer over the core mod_python handler mechanisms.
These amount to mostly Python code, although mod_python.psp has a
C code component, but that isn't part of the Apache module, but a
loadable
Python extension module. Thus neither actually affected the footprint of
the Apache module when not in use.
Thus, there probably is very little to be gained from doing a split
and in
practice it would probably make it harder to manage the code base as
far as releases and maintenance.
The particular use case I was seeing this as being targeted at was so
as to be
able to implement a mod_dav_python. That is, mod_dav_python is
primarily
a C based module which hooks into mod_dav and bridges the C hooks
into hooks
implemented in Python. The mod_dav_python would need to provide
Python
wrapper classes for all the mod_dav structures, but at least it
doesn't have to
duplicate what mod_python does in the way of interpreter
management and
wrappers for request object etc. Overall this could allow a mod_dav
filesystem
to be implemented in Python.
Hmmm. I'm not sure I see what you mean. Providing python hooks in
mod_dav
ops would surely be a relatively simple extension to the existing
mod_python?
The issue is more that mod_dav support shouldn't belong in mod_python
itself. It should be ignorant of other Apache modules. If mod_python
itself
had dependencies on other modules, it makes it harder to develop as you
have to bring into the core development team people who have intimate
knowledge of the other packages. The only exception we have made to that
ideal is that the request object in mod_python in unreleased code
hooks in
optional functions of mod_ssl because of its basic importance. That was
purely out of convenience as it had been demonstrated how to make a
standalone Python module which achieved the same end.
XMLNS bindings would enable people to script SAX2 callback events
in Python,
and mix-and-match with C modules, all running in an XMLNS filter.
How does
that look from your PoV?
Can't see why it couldn't be done. The next version of mod_python hooks
into mod_includes to allow Python code in SSI files. What you are
talking
about doesn't sound much different.
The same set of optional functions exported from mod_python may be
useful for
implementing your suggestion. It is certainly a preferable approach
to making
mod_python understand something like mod_dav and embedding the
support
within it as standard.
Right, yes. It looks like a potential fit:-)
Only problem is that there is a bit of cleanup work in internals of
mod_python
before the optional functions could be put in place. I'm slowly
getting there
though. :-)
Anyway, in terms of the request for projects, if these optional
functions were
exposed in mod_python, am sure it could be a trigger for a number of
interesting projects.
Graham
