On Aug 23, 9:34 am, Mike Orr <[email protected]> wrote:
> On Sat, Aug 22, 2009 at 3:36 PM, Graham
>
> Dumpleton<[email protected]> wrote:
>
> > On Aug 22, 2:48 pm, Didip Kerabat <[email protected]> wrote:
> >> From my experience both are not ridiculously hard to deploy. Even
> >> though pylons have more options. It's a hard sell on that one, i
> >> think. On the other hand, isn't django having problem with wsgi?
>
> > Care to elaborate on what supposed problems Django has with WSGI
> > rather than leaving a cloud of doubt with no explanation?
>
> Django was made before WSGI and has had some trouble adapting to it.
> Using Django in a WSGI environment has required some significant
> hacking,
The only real problem was that they didn't honour SCRIPT_NAME as mount
point. That was fixed back before 1.0 came out.
> and it seems that resolving these issues has not been a high
> priority for them because their native servers work just fine thank
> you.
There native server is a development server and they stress that it is
not for production sites. Thus they are dependent on other hosting
mechanisms and it is stretching it a bit to suggest that they don't do
stuff because their native server works fine. You can't even say that
they delayed doing things because mod_python support worked fine
because that was broken as well for mounting at a sub URL and still
requires a hack by virtue of user having to duplicate that information
through a configuration option. That there is an issue with that is
mod_python's fault though and not Django.
> It comes out of their different philosophy. Django
> users/developers are happy if it works in its own separate world.
> Pylons/WSGI enthusiasts are obsessed with interoperability
The only thing I can see that anyone could draw an issue with here is
that they have their own middleware interface and don't use WSGI
internally. Irrespective of the fact that Django existed before WSGI,
doing it that was is really a design decision and if someone wrote a
Python web framework now they could make the same decision to ignore
WSGI for internal interfaces. Part of the discussions going around
about WSGI is not to use WSGI for that internal interface because of
WSGI being inadequate for it to a degree. So, that they are a
monolithic application and have their own middleware system for
bringing components together is hardly a point to be criticised on. It
is a valid alternate way of doing things and will be attractive to
some users over a more loosely coupled componentised type system.
> > FWIW, hosting Pylons on anything besides Paste HTTP server can also be
> > a problem in some cases. This is because certain setup steps for
> > logging expected by Pylons applications are embedded in Paste HTTP
> > server where they should not really be. This means that those magic
> > steps have to be some how duplicated when using alternate WSGI hosting
> > mechanisms. Such steps aren't though even documented in Pylons
> > documentation, unless that has changed since last time I looked.
>
> > So, in that respect, as a self contained WSGI application/component,
> > Pylons isn't actually a good WSGI citizen.
>
> The logging setup needs some improvement but that's not a WSGI issue.
> WSGI doesn't address logging. I'll address the technical problem in
> another thread.
But it is a deployment issue. I am not suggesting here that these
things should be a part of WSGI but a separate abstraction is needed
to encompass them to make hosting easier through single recipe that
works everywhere, unlike now where users have to work out how to
customise it, but where many packages don't make it easy to deploy on
anything but their favoured hosting mechanism, mainly because of lack
of documentation on what is required.
> > Part of the problem here is that there is no standardised model for
> > deployment of WSGI applications. WSGI defines the interface, but
> > doesn't cover the deployment of that in a standard way such that there
> > is one story for all hosting solutions. As a consequence, all Python
> > web applications using WSGI to adapt to the underlying web server have
> > their own caveats and extra things you need to do. Things can get
> > worse again when you are trying to plug a WSGI application as a
> > component into another application structure.
>
> WSGI has grown way beyond its original scope. And nobody knew what
> issues would arise with mod_wsgi because it didn't exist. I don't see
> how you can get around the fact that every web server or Apache module
> is unique. Not to mention every daemon manager on every platform.
> WSGI is just a Python protocol; it doesn't address those issues.
I wasn't thinking specifically about mod_wsgi when making these
comments but any hosting mechanism. Yes hosting mechanisms may be
unique, but there is nothing to stop a higher level concept of hooks
for defining initialisation and access to application entry point
which specific hosting mechanisms could interface with. Concepts from
Paste deploy, buildout and bits of CherryPy could be brought together
to achieve this.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
