[mod_python] mod_python and mod_dav

Graham Dumpleton grahamd at dscpl.com.au
Sat Feb 25 06:56:55 EST 2006

The JIRA web site is down at the moment, otherwise I would refer you
to patches for mod_python that allow callouts from mod_include (ie.,
server side include) into mod_python. In this case though, what is  
is for mod_python to export the optional functions so a mod_dav_python
module could call it, which is opposite to that for mod_include where
mod_python is a user of the functions.

Getting late here, so I'll post more about the whole mod_dav issue  
when JIRA is working again. I think I even understand what functions  
to be exported now, so may be able to post some patches for it if you  
or some
one else wants to seriously pursue this.


On 25/02/2006, at 10:19 PM, Troy Kruthoff wrote:

> Graham,
> The below link describes making mod_include call into mod_cgi, so I
> get how cool it would be to have the proper APR_RETRIEVE_OPTIONAL_FN()
> interfaces for mod_python.  This looks like it may be beyond my scope,
> but if no-one else is looking at doing this anytime soon I can take a
> look at it.  Although I'd probabely be more of a help putting the code
> behind the interface created by someone more familiar with the
> workings of mod_python.
> http://www.onlamp.com/pub/a/apache/2001/09/27/apache_2.html
> Troy
> On 2/25/06, Graham Dumpleton <grahamd at dscpl.com.au> wrote:
>> On 25/02/2006, at 8:55 PM, Troy Kruthoff wrote:
>>> I'm trying to figure out the best way to add webdav capability to a
>>> mod_python web app.   In short, I want to send/update calendar files
>>> via calendar information stored in a database.  I've googled for
>>> python based webdav server modules, and found 2, but the newest one
>>> was last updated in 2000.
>>> My first thought was to write something in C that allowed mod_python
>>> to control mod_dav, but this looks tricky and looks like it will  
>>> take
>>> me too long and crush my ego by confirming that I suck at C.
>>> Second thought is to dig up the wevdav RFC and make a webdav server
>>> module that will work as a mod_python handler (or at least called  
>>> from
>>> one).
>>> Third thought is to use a fixup handler.  This is where I'd really
>>> like some feedback!  Can I (in a fixup) ascertain that the content
>>> handler will be mod_dav, query the database, and write the requested
>>> file to disk just before mod_dav is asked to push it to the client?
>> I have a idea of how mod_dav_python could be constructed. I had put
>> the idea on the back burner for the moment. Here is email where I  
>> have
>> posted a little bit about my ideas before when someone raised the  
>> idea
>> of mod_dav/mod_python integration.
>> See below:
>>> On 30/01/2006, at 9:49 PM, Matt Carpenter wrote:
>>>> Graham Dumpleton wrote:
>>>>> Others may know what you are talking about, but I plead ignorance.
>>>>> Can
>>>>> you perhaps describe further what you are talking about, how it
>>>>> would be
>>>>> used etc. A URL to stuff that could be read to understand similar
>>>>> things
>>>>> would also help.
>>>>> Graham
>>>> What I am trying to achieve:
>>>> I'm writing a module for our system for managing documents that're
>>>> attached to records in our database, updates to these documents are
>>>> recorded into the database along with what user made the user that
>>>> made the edit, and various other information depending on what type
>>>> of document (the system manages templates, and mailmerges with
>>>> virtual .csv files pulling data from the database as well). The
>>>> directory structure is entirely virtual, the structure on the
>>>> servers is just a few directories for each type of file, and the
>>>> files are named after their record in the database.
>>>> mod_dav implements hooks (see http://mailman.lyra.org/pipermail/ 
>>>> dav-
>>>> dev/2005-April/005926.html), but I'm not a C programmer, so I'd
>>>> like a these hooks to be able to call python functions instead.
>>>> Hope that makes sense.
>>> Regardless of how you might use it, from a technical standpoint I
>>> would say that it is not going to be possible at present.
>>> One could imagine being able to write a separate C based Apache
>>> module
>>> which provides Python based wrappings for the DAV specific data
>>> structures   that the repository hook function use. As documented  
>>> in:
>>>    http://docx.webperf.org/structdav__hooks__repository.html
>>> But, there are a few things missing. First, is there is no way to
>>> obtain references to the Python interpreter instances held by
>>> mod_python, the mechanisms for creating them and acquiring locks
>>> against
>>> them from a distinct Apache   module. Similarly, there is there  
>>> is no
>>> way to access the mod_python Python   request_rec wrapper object  
>>> etc.
>>> Both of these and possibly other stuff would be required. You do not
>>> want to go having to duplicate all this stuff as it sort of defeats
>>> the
>>> purpose   and would possibly prevent use of mod_python and your  
>>> module
>>> in the same Apache instance.
>>> What would be an interesting area for investigation in the future
>>> would be to work out whether there are functions within the  
>>> mod_python
>>> module   which could be exposed using the Apache
>>> APR_RETRIEVE_OPTIONAL_FN() interface. This would allow distinct
>>> modules
>>> to dynamically obtain references to   some of the internals of
>>> mod_python so as to perhaps make use of all the   machinery it has
>>> already for manipulating Python interpreters, as well as   existing
>>> Python object wrappers for Apache structures.
>>> The end result would be the ability to create distinct C based  
>>> Apache
>>> modules which themselves can also make use of Python by
>>> bootstrapping of
>>> mod_python. It may be tricky to work out how to do it and come up
>>> with a
>>> good   interface design, but certainly would be interesting.
>>> Graham

More information about the Mod_python mailing list