Hi,
Not sure if this is best posted here, or to mod_dav mailing list. But
here goes.
Has anyone looked at using mod_python to backend mod_dav, with a
similar usage to FUSE's python binding. Basically mod_dav_python.
Thanks,
Matt
--
Matt Carpenter
[EMAIL PROTECTED]
FCP Internet LTD
Unit 3,
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 t
Jim Gallacher wrote:
Barry Pederson wrote:
I think this is the general kind of thing we're looking for though,
with some mistaken pointer/memory operation.
Too bad we can't write *everything* in python. :(
You haven't been following PyPy then? :-)
David
Gregory (Grisha) Trubetskoy wrote:
On Sun, 29 Jan 2006, Graham Dumpleton wrote:
buffer += bufsize;
On a second thought - yes, you're right :-)
And if he's not then there is a bug in filter_read since that is what it
does and it is very similar to _conn_read.
Jim
David Fraser wrote:
Jim Gallacher wrote:
Barry Pederson wrote:
I think this is the general kind of thing we're looking for though,
with some mistaken pointer/memory operation.
Too bad we can't write *everything* in python. :(
You haven't been following PyPy then? :-)
David
Well, sure,
Graham Dumpleton wrote:
What I might speculate is that if the test in mod_python for the
connection handler is setup to run on a secondary listener port,
but with the primary still active, that it may trigger the problem
on other systems like Linux. Jim, you might want to try this and see
if you
On 30/01/2006, at 9:11 PM, Matt Carpenter wrote:
Hi,
Not sure if this is best posted here, or to mod_dav mailing list.
But here goes.
Has anyone looked at using mod_python to backend mod_dav, with a
similar usage to FUSE's python binding. Basically mod_dav_python.
Others may know what you
Getting a bit closer now, have next part of puzzle worked out.
Graham Dumpleton wrote ..
> This is starting to look really ugly.
>
> In _conn_read(), it first creates a bucket brigade from the connection
> objects pool object. No chance of this being destroyed prematurely
> as a result.
>
>
This may be a good question to post to dev@httpd.apache.org
Grisha
On Mon, 30 Jan 2006, Graham Dumpleton wrote:
Getting a bit closer now, have next part of puzzle worked out.
Graham Dumpleton wrote ..
This is starting to look really ugly.
In _conn_read(), it first creates a bucket brigade
Graham Dumpleton wrote ..
> Returning back up to _conn_read() in mod_python source code, we have
> where core_input_filter() was called ap_get_brigade():
>
> Py_BEGIN_ALLOW_THREADS;
> rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ, bufsize);
> Py_END_ALLOW_THREADS;
>
Graham Dumpleton wrote ..
> Extending the above code as:
>
> Py_BEGIN_ALLOW_THREADS;
> rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ, bufsize);
> Py_END_ALLOW_THREADS;
>
> if (! APR_STATUS_IS_SUCCESS(rc)) {
> PyErr_SetObject(PyExc_IOError,
>
Jim Gallacher wrote:
Graham Dumpleton wrote:
What I might speculate is that if the test in mod_python for the
connection handler is setup to run on a secondary listener port,
but with the primary still active, that it may trigger the problem
on other systems like Linux. Jim, you might want to t
Graham Dumpleton wrote:
Graham Dumpleton wrote ..
Returning back up to _conn_read() in mod_python source code, we have
where core_input_filter() was called ap_get_brigade():
Py_BEGIN_ALLOW_THREADS;
rc = ap_get_brigade(c->input_filters, bb, mode, APR_BLOCK_READ, bufsize);
Py_END_ALLOW_
An initial few comments from a first pass through.
def _write(self, request, response, content_type='text/xml'):
request.send_http_header()
request.content_type = content_type
request.write(response)
This is technically wrong, although it doesn't matter on mod_python >
14 matches
Mail list logo
