Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 12120 invoked from network); 17 Apr 2006 11:52:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Apr 2006 11:52:20 -0000 Received: (qmail 8674 invoked by uid 500); 17 Apr 2006 11:52:19 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 8621 invoked by uid 500); 17 Apr 2006 11:52:19 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Delivered-To: moderator for dev@apr.apache.org Received: (qmail 63714 invoked by uid 99); 17 Apr 2006 06:46:05 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) In-Reply-To: <200604170727.14232.nick@webthing.com> References: <5E1BAEAF-ABEC-4002-84E5-8235FAAE74B9@holsman.net> <200604170727.14232.nick@webthing.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: dev@apr.apache.org Content-Transfer-Encoding: 7bit From: Graham Dumpleton Subject: Re: It's that time of the year again Date: Mon, 17 Apr 2006 16:45:23 +1000 To: dev@httpd.apache.org X-Mailer: Apple Mail (2.749.3) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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. 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. 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. Graham