I'm pretty sure you said a good amount of this when we chatted at Monk's, so I may be regurgitating more than I think, but here are the two key things from this post for me:
So many other salient Zope comparisons, not all negative. I'll highlight one other as a possible future: I would not be surprised to see Ruby web development take a similar path to what we've gone through in the python world. Zope was THE web framework for Python, and brought a lot of new people to Python. Perhaps because of the second-generation issue, perhaps because of other differences of opinion, other frameworks start to gain traction and we ended up with the fractured web landscape that people are whining about today. Strangely, up until Rails it seemed like the Python community had come to accept the conclusion that a diverse set of frameworks was OK except that we obviously couldn't answer the generic question "I like python and I want to make a website". The python web world had disintegrated into a variety of tools with mildly different strengths and moreso different philosophies. Which leads to:
But I am moreso in your camp, that being able to create a mixed stack of frameworks is the third step and the only one that is wholely based on the conclusion that integrating disintegration shouldn't ignore the differing reasons that lead to that disintegration.
In conclusion, quotes from your post: "The 'Frankenweb' is a feature, and it describes the web we have, the software we have, and the future that is inevitable." And: "The project that is reusing code right now will be able to reuse code in the future."
Also, I was going to say something about Acquisition reminding me of how DRY has some nuances to it that often get left of the picture in favor of primarily avoiding any duplication of typing - fits in with the SQLObject/ActiveRecord pluralities thing too. But no time now.
Fitting together components and frameworks. Some people seem to think the solution to the fractured landscape is to build a new complete-stack system. But that's precisely the reason I expect Ruby to end up in something like our current state. Turbogears/Subway are taking the next-best step of combining components, and I think it's logical and worthwhile. I think they will be more able to adapt and incorporate new ideas than the monolithic systems, and therefore less susceptible to dissolution because they incorporate the reality of disintegration as part of their design strategy.
While I agree, I should say that this doesn't somehow invalidate efforts to build good APIs and frameworks on the level that TurboGears and Django are working. That still needs to be done; this is about enabling that kind of work, not superceding it. Nor does it invalidate efforts to provide a complete development story, which is what both Django and TG are doing; it's just notable that TurboGears is doing that without having developed each piece that is part of that story.# Ian Bicking
While I want to support the idea that it should be a natural thing to integrate an existing app/sub-app or to develop a piece of your system in a different framework/language because it is by far the better tool for that purpose, you're also right that having a complete story is preferrable in a large number of situations. The reaction I'm having is because Rails and Django (and at a only somewhat different level, TG) so far don't seem to be considering (or are rejecting) the heterogenous reality you refer to.
But maybe I've also been ignoring the point of your plan, which is that this is all perfectly fine because we won't need to convert the philosophies of any frameworks (an effort bound to fail), we're just going to create an interoperability between frameworks (including frameworks that haven't been written yet). So there only has to be agreement on how to integrate, no agreement on how much or how little or how best to do things inside a framework. Someone looking for a complete story in a style they like can be happy there, but not have to give that up when they want to add something someone else wrote in a different framework.
Right; you shouldn't force people to reuse and share code. That's just another name for a big all-encompassing framework. Well, you do have to force it on some level, and I want to do that. But that's not about aesthetics so much as functionality. So WSGI is one of those levels; but WSGI is a well-specified API that is very closely tied in heritage to CGI, and in functionality HTTP, both good choices. Eggs are another one of those things. And I want Paste Deploy to also be part of that -- simple and relatively formal ways of indicating configuration and creating an application, as well as stronger promises about isolation than WSGI alone demands. But none of these are meant to be about APIs and aesthetics; I hope that these all can be streamlined and made easy/invisible/automatic by the complete-story framework developers.# Ian Bicking
I feel a bit odd saying this, as I am a TurboGears fan, but this meme that TurboGears is repackaging components better than Django is ... well, a bit of our own hyping, isn't it? There were plenty of templating engines for Python before Kid came along; there were plenty of other web stacks than CherryPy --- that Kevin chose to build on these was his decision, his opinion. SQLObject definitely has an opinion of how to interface Python with an RDBMS. Everytime someone picks at Django for "rolling their own" it comes across as dissing them for having an opinion. (Especially as these conversations usually end with the caveat that "Oh, well, Django's been around long enough that they pre-date Kid and the improvements to SQLObject and blah blah blah...")
It's a bit sad, as this should be an amazing time for Python --- both Django and TurboGears providing all the parts and glue are an amazing achievement, in very little time.# Roger Espinosa
Concerning the state of Zope, we've have a movement inside the Zope community to merge our diverse subcommunities together; we've got Zope 2, Zope 2 + CMF, Zope 2 + CMF + Plone, Zope 2 + CMF + CPS, Zope 2 + Silva, Zope 3, and more. I helped formulate some of the strategy and code (Five, which is Zope 3 in Zope 2) over the course of 2004, and this really gained steam and acceptance in many of our subcommunities over the course of this year. Now there's an exciting revival of development of Zope 2 (we put in pieces of Zope 3), Zope 3 is ready for prime time, and overall the situation in the Zope world is looking up in my perspective. Communities are integrating and we're working together much more. Zope 3 getting ready was of course the catalyst for all this activity.
The next obvious step on this path is to integrate Zope better into the rest of the Python community. Zope has influenced the Python community for a long time of course in many different ways (new style objects are there in Python now in part due to requirements Zope corp had, and earlier Jim was instrumental in introducing metaclass hooks), but it's time for Zope to eat the humble pie and start reusing more what others did. Philipp von Weitershausen describes how this is happening. He also mentions that nobody knows about this; developer marketing is another Zope problem that's way past time we tackle as a community.
So, because of my experience within the Zope community I have some idea of where you're coming from and where you're going. Aligning, by word and code, subcommunities to work together in their common interest can be extremely beneficial to everyone involved, so I'm happy you're around and thinking about how to do this so much. Thank you!