httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <grah...@dscpl.com.au>
Subject Re: It's that time of the year again
Date Mon, 17 Apr 2006 09:22:44 GMT

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

Mime
View raw message