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.
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