I was there and I have this pretty screenshot to prove it! :)
Maybe even more importantly, TurboGears has a new leader: Alberto Valverde.
I was too busy to stay there for the followup discussions, but the gist of it seemed to be that a heavily WSGI based approach (sounded much like Pylons) will solve all problems including world hunger and the conflict in the Middle East.
Another equally important thing was the direction that is planned for TurboGears 2.0: decentralization and modularization. From what I understand people want to fork off chunks of TurboGears into fairly independent and externally reusable projects and keep TurboGears a small chunk of glue code that connects them together.
On the one hand this is not new, TurboGears started out by integrating a bunch of preexisting tools. ToscaWidgets was forked off recently from the TurboGears widget code. I agree that this approach can work to a certain extent. My guess is that in the case of TG the current change of direction (actually returning to its minimalistic roots) was more organizational than architectural. (Not that you can separate the two: see Conway's Law)
But there are pros and cons to decoupling. Unix command line tools are a good example. They were great, because there were standard interfaces between them which let them develop and be tested independently. But there is also a huge lack of conceptual integrity compared to monolithic frameworks. The naming conventions are inconsistent, different switches are used for the same functionality in different programs, etc.
The big advantage of monolithic frameworks is consistency in design. Modules use the same naming and coding style, have similar layouts. They reuse the low level utility code, the documentation tool, the testing framework, the bug reporting, the build and packaging system. There is one well known place to ask questions, to look for documentation, to download the latest stable release.
Linux distributions are a good example of both the strengths and weaknesses of heavily modularized systems. Probably the biggest advantage is that there is a huge amount of code reuse, and you can decentralize work to thousands of volunteers, maintaining the individual packages which can evolve independently.
On the other hand some combinations of packages are not tested properly, only certain combination of packages are well supported. If you report a bug that has been fixed in the upstream version, but not in your distro, you're on your own. Linux and Firefox is a good example.
People who want to support your software have a harder time when instead of a standard way, you have an infinite combination of modules. Just think of LSB and desktop Linux vs Mac OS or Windows.
We'll see how loose coupling works out for TurboGears. Interesting times ahead.
Blog feed
3 comments:
Obviously, I think the proposed decoupled approach is a good one, since I've been championing it. But, I think it was reasonably proved out with the original TG release. Kid, SQLObject and CherryPy are all independent Python packages, but they felt quite good together with a little bit of glue.
TurboGears has since added a whole bunch of functionality. The intention is not to change the nature of what TurboGears offers, but just to make the whole more manageable and agile. It'll be easier for someone to dive into a particular part and try things out.
TG is already modular on the inside, but I can see it being daunting for someone who's new to the project to check it out from svn and start hacking.
Time will tell if the strategy pays off. I really do think the project will be more nimble and useful as a result.
Kevin, I do hope that it does pay off. I invested too much of my precious little free time into learning TurboGears already. ;)
I think "single implementation" is easier then "diverse implementations", but diversity can lead to standards and these can be really empowering. WSGI ole!
Post a Comment