[mod_python] mod_python and mod_dav

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