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
