On Sat, Aug 22, 2009 at 8:34 PM, Graham Dumpleton<[email protected]> wrote: > > 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.
Coming back to the advantages of Pylons, a loosely coupled system makes it easier to switch in an alternate implementation if one meets your needs better or is better maintained. And a framework devoted to industry standards (in this case, the Python web developer community) can adopt innovations quicker. This applies to both the receiving end and the giving end. If an adequate standard exists, you use it. If not, you make another one, ideally working with other similar users (frameworks) to design something you can all use, or at least making it work standalone so it can theoretically be used by other software if any should come along. With a monolithic framework, you have to wait until the developers implement the innovation, if they ever do. And if they do develop something generally useful, it's so tied to the framework it can't be used outside it. Thus the rise of Jinja, a reimplementation of Django templates because the native one couldn't be used outside Django very easily. If you look at the App Engine code, where they did try to use Django templates & dispatching outside Django, they had to make some ugly hacks and simulate global variables in order to get it to run. Contrast this with TurboGears, which has given us ToscaWidgets, repoze.what, and some less successful spinoffs (Buffet, Catwalk). When WSGI came out, other frameworks besides Django also added it on, for instance CherryPy. That works but it still seems kludgy. I'd argue that WSGI was such a monumental step that it deserves to have frameworks written from the ground up to use it, which is what Pylons is. And plusgood that Pylons integrates with "paster create", which has been good enough that other frameworks have followed suit. >> 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. It sounds like you're about to propose a new standard for logging and ... I'm not sure what other higher-level initialization & access you have in mind. But it's a great example of interoperability in action. Re logging, none of the frameworks I've used before even used the Python logging system, much less clamored for a standard way to enable it. So you're charting some new ground here. In Quixote, logging is simply print statements that get written to the errors file. Pylons made an innovation, carefully logging to a variety of loggers and levels that could be finely tuned by the logging configuration. And several of Pylons' dependencies did the same thing. So the great thing is you get logging at all, and that should also be mentioned as an advantage of Pylons. If it's not working in mod_wsgi (I only noticed it not working in standalone utilities), we'll have to do something to make it work. -- Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
