Could the difference between a 'glue' and 'full stack' framework be summarised as ... If, as a framework representative I find a third party module that does something significantly better;
Or would it be OK to use the third party module as long as it becomes a component part of the "full stack" framework..
Or! If MochiKit, Kid, CherryPy and SQLObject all shared a single svn repository and all prefixed their project names with 'TG' would it then become a "Full Stack" framework?
If so then the definition is virtually meaningless..
Tim, personally I think it comes down to development focus: does the framework primarily focus on a single set of components, and provide support and maintenance for those components and for the code it uses to hook them together? If so, it's full-stack ("coupled" in Ian's terminology), and you don't have to develop all your components in-house to do that -- you could, for example, use someone else's open-source components and distribute patched versions which work with the rest of your framework (and to be a good citizen you'd submit those patches back to the original project, of course). On the other hand, you can primarily focus on developing interfaces and adapters which aren't meant for any specific component or set of components, but rather to be generic enough to plug any component into any slot in the framework; that's what I mean when I say "glue" and what I think Ian means when he says "decoupled". And you don't have to use only third-party stuff as your default set -- you could develop an ORM, template system, etc. and offer them as the default set.
Either way it's a lot of work -- supporting a specific component stack is non-trivial, and neither is developing a full WSGI system with the necessary support and adapters to truly support "plug and play" components. I'm incredibly glad there are dedicated people on both sides who are willing to put in the time and effort to give the Python community the embarrassment of riches we have in the web-dev sector now, because I remember all too well the days when I desperately wanted to use Python on the web but couldn't because Zope was the only option and wouldn't fit in my head :)
This is where things get confusing.
TurboGears does, as a simple matter of fact, pull together a single set of components, and encourage their use. We are trying to tell a unified story about how everything works together, and we've had help from CherryPy, Kid, and other components in bringing everything together in the way we want.
Let's look at the way we work with templating systems. We clearly aren't distributing a patched version of Kid, but the Kid maintainer is doing it because he uses it in TurboGears. When you use a kid template you just specify the name of the template in the @expose decorator, and everything "just works."
So far we are just like Django and the Django templating system. Simple defaults, and easy configuration make life good. But we do have a differnt philsophy. The maintainers of Kid understand that some people will want to use Kid in other ways -- outside of the framework -- and they work to support that.
At the same time we also understand that some people have hundreds of thousands of lines of template code written with Cheetah and we support them if they want to use TurboGears. So, we've allowed them to define the engine they want used as well as the template name in the @expose decorator.
And that's the difference between the TG/Pylons way and the Django way. It's not Glue VS Full Stack (TurboGears at least tries very hard to be Full Stack). It's about code reuse. We are open to pulling in code from outside and working with those developers to get what we need from their components, and we are open to the idea that others will want to use some of our components outside of our world.
Of course this is a trade-off, we're dependent on the good judgement of the people who work on Kid, unless of course we want to fork the project.
Now, I think TurboGears is doing the right thing here, but I also think there is a benefit to the centralized control that the Django guys have.
The documentation story in TurboGears is harder, because we have to pull together a clean story that includes each of the components we use. And because those projects all have a lot of internal innovation going on, it's a lot harder to keep up with all the cool new stuff that's coming in. We're definitely struggling with how to do that in the best way.
So, I recognize that we're traiding away some control of our own destiny, and inviting extra documentation and bug-tracking work, in order to get better code-reuse, cleaner decoupling, and more end-user freedom.
As Jacob once said, "it's trade-offs all the way down." I'm happy with the trade-offs we make, even though there is a cost.
I'm sure you're happy with the trade-offs you make. But you should admit that there is a real cost there too.