Another competitor to mod_wsgi.

[Graham Dumpleton]

Here we have someone else who wants to compete with mod_wsgi in the
Apache space. It is called uWSGI.

http://projects.unbit.it/uwsgi

I have yet to look through code too much yet.

FWIW, I have been looking through Phusion Passenger code of late and
their Apache module is a bit of a mess. Phusion Passenger chose the
wrong way of hooking into Apache request processing phases and as a
result it doesn't interoperate properly with some other Apache
modules. Rather than realise their mistake, that have just been adding
more hacks on top to try and get it to work properly with the other
Apache modules.

I wander what surprises I will find in the uWSGI code. Their use of
Python sub interpreters and multithreading appears to be flawed on
first glance.

Graham

[Hongli Lai]

On Apr 28, 3:06 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:

> FWIW, I have been looking through Phusion Passenger code of late and
> their Apache module is a bit of a mess. Phusion Passenger chose the
> wrong way of hooking into Apache request processing phases and as a
> result it doesn't interoperate properly with some other Apache
> modules. Rather than realise their mistake, that have just been adding
> more hacks on top to try and get it to work properly with the other
> Apache modules.

I'm interested in why you think we're doing it wrong. Could you tell
me more? There's very little good Apache module documentation out
there and I'm not even aware of a different way to do the same things
that we're doing right now.

[Graham Dumpleton]

2009/4/28 Hongli Lai <hong...@gmail.com>:

For a good explanation of how Apache internals work see:

http://www.fmc-modeling.org/category/projects/apache/amp/Apache_Modeling_Project.html

There are also books one can buy:

http://www.amazon.com/Apache-Modules-Book-Application-Development/dp/0132409674/ref=wl_it_dp?ie=UTF8&coliid=I3HAU1SZOASF2N&colid=1ENAXIJG1G044
http://www.amazon.com/Writing-Apache-Modules-Perl-C/dp/156592567X/ref=sr_1_1?ie=UTF8&s=books&qid=1240918768&sr=1-1

The source code for builtin Apache modules also serve as good examples.

Basic issue is that in the main Apache works based around having
actual files in the file system and mapping URLs to them. A lot of
functionality derives from that basic premise. When you start to move
away from that, things will start to fall apart if you still need to
have other Apache modules which work based on that assumption to
function properly.

So, although how you have done it can be made to work, I wouldn't view
it as the best way of doing it and a lot more fiddles would probably
be necessary. It is worthwhile mentioning that mod_python also avoids
the more natural file source based view and it also can be a PITA at
times because things like application mount points cannot be
calculated correctly and it breaks the Apache security model for
controlling where users may point the file that is the application
entry point.

Anyway, lets just say I wouldn't do it the way you have done it. But
then your perceived requirements may have been quite different and
thus why you chose the way you did rather than other options
available.

BTW, I note that there are a few incorrect statements on your web site
about how Apache works. I recently sent an email to the contact email
address for your site pointing out one of them, but didn't get any
response.

Graham

[Hongli Lai]

On Apr 28, 2:09 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:

> BTW, I note that there are a few incorrect statements on your web site
> about how Apache works. I recently sent an email to the contact email
> address for your site pointing out one of them, but didn't get any
> response.

Good thing you pointed this out. It was recognized as spam. I'll have
a look.

[Hongli Lai]

On Apr 28, 2:09 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:

> The source code for builtin Apache modules also serve as good examples.
>
> Basic issue is that in the main Apache works based around having
> actual files in the file system and mapping URLs to them. A lot of
> functionality derives from that basic premise. When you start to move
> away from that, things will start to fall apart if you still need to
> have other Apache modules which work based on that assumption to
> function properly.
>
> So, although how you have done it can be made to work, I wouldn't view
> it as the best way of doing it and a lot more fiddles would probably
> be necessary. It is worthwhile mentioning that mod_python also avoids
> the more natural file source based view and it also can be a PITA at
> times because things like application mount points cannot be
> calculated correctly and it breaks the Apache security model for
> controlling where users may point the file that is the application
> entry point.
>
> Anyway, lets just say I wouldn't do it the way you have done it. But
> then your perceived requirements may have been quite different and
> thus why you chose the way you did rather than other options
> available.

I've read parts of those resources but it didn't seem to me that they
provided alternative solutions for our requirements.

One of our requirements is that things must be as simple as possible,
even for people who don't understand Apache. "Magical", if you will.
mod_wsgi requires one to specify "WSGIScriptAlias" and "SetHandler",
but this is already too complicated in our opinion. Much of the
perceived workaround code is to implement this "magic".