httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: It's that time of the year again
Date Mon, 17 Apr 2006 08:43:14 GMT
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

> 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?
Though it does sound like a pretty similar task to providing DBD bindings.
Maybe this is because I've not looked at mod_python from a C perspective.

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?

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

Nick Kew

View raw message