UPDATE: If you want see an “application”, Plone 3.0, run under WSGI with a “framework”, Grok, you can check out this demo on the Repoze Site. This is one of the more exciting things I have seen all year. So what is this called, a framework, a product, WSGI…you tell me
Our local Atlanta, Python User’s Group, PyAtl, is collaborating with the local, Plone User’s Group, to build a Plone 3.0 site. I have been attending the Atlanta Plone meetings recently at ifPeople, and we had a mini-sprint last weekend where we got a demo site running behind a, newish, forward proxy server called Varnish.
On Wed, I attended an Atlanta Plone meeting, where Brandon Rhodes, gave a presentation on Grok. Brandon has kindly agreed to post his presentation on his blog, which he did in KeyJnote, which is written in Python, of course.
In Brandon’s talk, he mentioned that Grok, which is built on top of Zope 3, is less of a framework and more of a component based architecture. In looking at the Grok website, I liked two things in particular:
1. Grok offers a lot of building blocks for your web application.
2. Grok is informed by a lot of hard-earned wisdom.
One of the reasons why web application developers should look at Grok, and Zope 3, in particular, is the second point. Failure over a long period of time, leads to experience. When people learn from their failures, it then turns into wisdom. The Python world has much to learn from Zope, and that is why I am especially interested in Grok, and Zope 3. Remember Zope Corporation was founded in 1995, a lifetime in software development.
All of this background information brings us to the meat of the discussion, which is Repoze, WSGI, and the eventual death of webframeworks as they exist in their current state. I for one, welcome our new WSGI, overlords. WSGI, and products like Repoze, will make webapplication frameworks much less important, and component based architectures, much more important.
One of the massive, unaddressed until WSGI, problems of standalone, web frameworks, is that, ultimately, they could never win in the long term. If a web framework has a frenzied pace of development, then the API, and documentation will never be accurate. Additionally, web frameworks, like Django, can lock you into a specific set of “tightly coupled” components, in which your ability to use other components, like SQLAlchemy, is not possible.
With WSGI, these issues become much like relevant, as something like Repoze, can use the WSGI spec, to do things like, “allow for systems that participate in a WSGI pipeline to make use of the existing two-phase commit transaction management provided by the ZODB transaction package.” WSGI is clearly the future for Python web development, and in hindsight, it even seems silly that such an emphasis has been placed on web frameworks as a one stop solution.
Clearly the better solution, is a loose set of components that work together in a unified fashion under one specification, much like how the standard library of Python itself works. I suppose, to further illustrate the point, can you imagine how irritating it would be if you used, say, the tarfile module, and that meant that you could not use the zip module? That would clearly be unpythonic, and this is why WSGI is the new buzzword. By using the WSGI spec, and optionally, something like Repoze, combined with deliverance,it is possible to run multiple web applications, running under one URL, all with the same “skinning”, or look and feel. This smells like victory, for Python web application developers.
Note update: I want to make it clear that I am not slamming any web framework, including Django, my point is that ANY web framework can run independently inside of something like Repoze, coupled with Deliverence, making even a full framework an actual component and in fact eliminating problems like one architecture is tied to a specific ORM, or templating engine etc.. My apologizes if this point was not clear in the original post. What this does is take the emphasis, and pressure, off of a site being one specific component architecture, or framework. A site won’t be a “Django site”, or a “Turbogears” site, it will be a “website”.
(Thanks to Derek Richardson, for being such a strong advocate of Repoze, WSGI, and deliverence, as much of this post is based on things I have heard for the first time from him. On that note, it is looking more and more likely that we have the authors of Repoze speak at PyAtl in December, 2007. If you are interesting in helping to sponsor this event, please contact me or Derek Richardson.)
