[tg-trunk] Re: State of the Gears
hi lukasz, i am not a core developer but i call myself a TG evangelist so i guess i can say something about this. as long as TG stays the same, i am not against building TG on top of pyramid. however do we really need that? TG is already working fast and smart enough. it has the libraries that we need for rapid prototyping or building applications fast. i haven't needed anything that doesn't exist in TG ecosystem but exists in pyramid's. another thing is pylons, as we know it, is dead. there will only be pyramid and pyramid users has a different understanding of development. they are choosing the long way because pyramid is not a full stack framework like TG. the ones who don't want to do it the long way are either coming to TG or going to django. from what you're saying i understand that you are not happy with TG. please tell us why. because as our community grows on both IRC and the ML, we get requests and many of them are taken into consideration. the core developers are trying hard to build a strong application and a happy community. because we believe we can pull it off. On Jul 8, 9:28 pm, Lukasz Szybalski szybal...@gmail.com wrote: Not everything was well done, though: The Pyramid merger announcement was handled poorly. I'll discuss the future with Pyramid more thoroughly below. We discussed what we want to see for this year, and I think our goals are more than reasonable. We want to get 2.2 out shortly (originally, we were thinking before Pycon, but I'm not sure we can after my absence of the past couple months). We want to get 2.3 underway, and we have some pretty decent sized plans for 2.3, and more on that below as well. We also have some plans for the website, some updates we want to see happen. We also want to find ways to expand the development team. We also discussed our need for Python3 support, though we don't have a firm timeline for that. Finally, we discussed the need for us to standardize on a JavaScript widget toolkit. Our plans for 2.2 are as follows: We want to either make or integrate a Widget browser. We're looking to switch to ToscaWidgets 2 by default, since they're about to release a stable version. We want to reduce the number of packages we have to show in our PyPI, in particular by repoze.what-quickstart and repoze.what-pylons. We also want to merge in work by Chris Perkins to make Object Dispatch into an external package named Crank. Our plans for 2.3 are as follows: Major speed improvements, possibly some backward incompatibilities will be introduced. We're planning on removing the dependency on Pylons entirely in this branch. Possibly we're going to replace the repoze.what/repoze.who packages as well as the default AuthenticationAuthorization mechanism. Our directions of inquiry for Python3 are as follows: We're going to look at marrow as a possible replacement for Paste. The other option is to look at Pyramid's Paste Replacement. We'll also need to evaluate other libraries and modules, as not everything is supporting Python3, and we need to move forward soon. For the JavaScript toolkits, we need to evalute Bootstrap, jQuery UI, and even Dojo. We did not come to a final decision at the time of the meeting, though it seems like we're going to settle on Bootstrap, based on recent conversations on the mailing lists. For the Pyramid merger, most of us who are using TurboGears are happy with the direction things are going for TG. After discussion, we came to the consensus that the product built on top of Pyramid that provides a TG-like layer should not be called TG3, but rather Orion. We're also leaning towards not promoting it as the evolution of TurboGears. TG isn't perfect, but we're happy with it, and want to continue to extend it, improve it, and make it vibrant again. To: Trubogears2 steering committee/TG2 Core developers My goal of writing today is to convince TG2 core developers to reconsider their plans for not using pyramid, embrace the new changes in pylons(pyramid), and reconfirm the state of the union between turbogears2 and pylons project. Turbogears2 pylons backbone was a great success, it consolidated python web frameworks, and provided a bigger community to compete with others like django, ROR and was probably the perfect choice to develop web applications fast. Now 3 years later Turbogears2 (1K Downloads since 04/2012) is still strong but pylons (11K Downloads) have merged with repoze.bfg(3K Downloads) to create pyramid(14K Downloads since 05/2012), which merged the web frameworks even more and brought over some of zope/plone community with it. What these number mean for turbogears future is that if tg2 reconfirms their ties to pyramid, it might become one of the most powerfull contender to django (212K downloads). What are some pro's and cons with following pylons evolution: Pro: --Features that pyramid is capable of would work by default in
[tg-trunk] Re: State of the Gears
Hi all. Lukasz asked me for feedback on the question of converting TurboGears to Pyramid. I should start by saying that although I'm involved in Pyramid and Pylons development and know a few TG developers, I've only followed TurboGears at a distance, and not since Orion was floated a year ago. So my perspective is more historical and long-term. Kevin's original vision for TG was to select best-of-breed components and integrate them into a framework. That was an excellent idea and inspired me personally, but it failed in the sense that all his original decisions became obsolete: Kid, SQLObject, Prototype and Scriptaculous, non-WSGI base. To be fair, WSGI came out after TG was created and raised the bar on what a framework should be. All frameworks at the time went through a difficult conversion. I used TG (pre-1.0) for a short time, but it was not stable enough at the time so I switched to Pylons. The developers knew before 1.0 that it would need a restructure, and so 1.0 was released as the old code while work progressed on a new base -- after some experiments like RhubarbTart, eventually Pylons was chosen as the base. The conversion to 2.0 was particularly traumatic on the user base, who felt that they'd adopted shiny new 1.0 and bought the book and in less than a year it was obsolete. On Sun, Jul 8, 2012 at 11:28 AM, Lukasz Szybalski szybal...@gmail.comwrote: For the Pyramid merger, most of us who are using TurboGears are happy with the direction things are going for TG. After discussion, we came to the consensus that the product built on top of Pyramid that provides a TG-like layer should not be called TG3, but rather Orion. We're also leaning towards not promoting it as the evolution of TurboGears. TG isn't perfect, but we're happy with it, and want to continue to extend it, improve it, and make it vibrant again. This sounds like a sensible solution to me. The biggest worry of users is to go through a compatibility trauma again. It may be feasable to make a 100% compatible API on top of Pyramid, but inevitably something or other will slip through and cause extra work for users. Also, the conversion of Pylons to Pyramid showed that the developers will end up adopting some new APIs as superior to the old ones, thus forcing the users to do so too. Either way, it means modifications to applications. If it's desired to retain compatibility *and* move into the future, then doing the former under the TurboGears name and doing the latter under a new name makes sense. Since Pylons is lightly maintained at this point, it would behoove TG developers to step up to maintain it and perhaps plan a Pylons 2.0. I have not heard anything about Orion besides rumors that it exists. Is it active? To: Trubogears2 steering committee/TG2 Core developers My goal of writing today is to convince TG2 core developers to reconsider their plans for not using pyramid, embrace the new changes in pylons(pyramid), and reconfirm the state of the union between turbogears2 and pylons project. Turbogears2 pylons backbone was a great success, it consolidated python web frameworks, and provided a bigger community to compete with others like django, ROR and was probably the perfect choice to develop web applications fast. Now 3 years later Turbogears2 (1K Downloads since 04/2012) is still strong but pylons (11K Downloads) have merged with repoze.bfg(3K Downloads) to create pyramid(14K Downloads since 05/2012), which merged the web frameworks even more and brought over some of zope/plone community with it. What these number mean for turbogears future is that if tg2 reconfirms their ties to pyramid, it might become one of the most powerfull contender to django (212K downloads). What are some pro's and cons with following pylons evolution: Pro: --Features that pyramid is capable of would work by default in turbogears, no rewrite of code would be required to take tg2 into python3 for example, take the speed improvements, etc... --All the components that were mentioned above from repoze.XXX would still be valid and would follow pyramid upgrades and no additional work would be required to get them working. --Any changes to Paste would already be done in pyramid. --Turbogears choice of most downloaded components as a default would bring over few users that have high learning curve because of pyramid default scaffolds selections. --More consolidation would mean more of most common packages would be available to users. -- Instead of splitting from pylons embrace the evolution of pylons would mean more users are reassured tg2 is the right choice to build on. I have long believed strongly in modularity, reusablilty, and interoperability. That's what led me to TurboGears, Pylons, and Pyramid. My sense is that Pyramid has a strong and flexible base. It can go with users to whatever gee-whiz technology may appear in the future. Its flexibility is also helpful when an application's direction
Re: [tg-trunk] Re: State of the Gears
Hi, Thanks for such a nice discussion. It cleared many a things/confusions that I had on TG development. We have just started using TG and its really a good and clearly laid framework to develop upon. Speed developments in TG2.2(rc) are visible. The choice to include bootstrap is very well thought of (from the responsive design perspective). Template engines choice is also good. And sqlalchemy, wow. From a future perspective, I just want to say that when future versions of TG comes, my application should not break(other than few required minor changes to the code). These are the things that matter to us rather that pyramid or something else at the core. Only thing, is that making the core i.e proposed pyramid part itself pluggable may help, iff it does not deteriorate speed in a big way. Thanks for TG. On Monday, 9 July 2012 09:11:05 UTC+5:30, Michael Pedersen wrote: There's no doubt that other frameworks are bigger, more widely used, and more popular. No argument from me of any sort. Arguing in favor of a merger by stating We have a better chance of taking down Django is not a useful argument, though, not for me. I don't devote the time I do to take down Django. I don't do it for money. I don't do it for fame. I don't even do it to help other projects improve, or reach any of those goals. I do it because I love TurboGears. This web framework is the first one I ever found that actually made *sense*. I'd tried others. I'd even written my own really bad one in PHP in the early 2000's. None of them ever felt wholly right, though. Always, some aspect was poorly done, or some piece always got in the way of my project, or the entire system just seemed designed to make easy tasks complex, and hard ones virtually impossible. TurboGears provides something that others have always seemed to lack: just the right amount of simplicity. When I go to work on a TurboGears project, I can navigate it easily. I can find and deal with the various pieces, and feel comfortable that I am actually finding what I need to find. When I need to make a change, I can feel comfortable that I am changing the right piece of code. TurboGears provides these things for me, and it makes coding with it into a joy. Arguing in favor a merger on the grounds that everybody can topple the Django beast will not sway me. I love what we have, and I feel that the future is bright. It's not an easy row to hoe, to be sure, but few things worth doing are. All of that said, I'll address the rest of the points, and reply to everybody. On Sun, Jul 8, 2012 at 2:28 PM, Lukasz Szybalski szybal...@gmail.com wrote: Assuming that we did the merger work, we would have some piece of code called TurboGears that is based on Pyramid. Keep that in mind for these responses. --Features that pyramid is capable of would work by default in turbogears, no rewrite of code would be required to take tg2 into python3 for example, take the speed improvements, etc... Unfortunately, this is not correct. We would be vulnerable to which specific version of Pyramid we coded against. If a benefit from Pyramid required changing the way we use an API, we could not gain that benefit until we updated the code. If a backwards incompatible change were made in Pyramid, we would have to update our code to fix it, or lock down which version of Pyramid we support. If we found a problem in Pyramid, we would have to rely on Pyramid to update before we could truly get it fixed. Furthermore, while Pyramid may be Python3 ready, we are not. Pyramid being ready or not has no bearing on whether our code is ready, and that's true regardless of anything else that may be going on. This pro has some benefits, to be sure, but it's not the bed of roses that is painted here. --All the components that were mentioned above from repoze.XXX would still be valid and would follow pyramid upgrades and no additional work would be required to get them working. The same problems and benefits as the previous item. --Any changes to Paste would already be done in pyramid. While this is true, since we're not at that point in our own development. As such, this item is not a consideration for us at this time. In future, maybe, but right now, no. --Turbogears choice of most downloaded components as a default would bring over few users that have high learning curve because of pyramid default scaffolds selections. Agreed on this point. This would help Pyramid adoption, definitely. --More consolidation would mean more of most common packages would be available to users. For consolidation, what I would actually look to provide is some way for modules to seamlessly make themselves available for multiple frameworks. For instance (and this may be a bad example), if we were to provide a webframework.model entrypoint, and all the frameworks were to honor it, then a given plugin
[tg-trunk] Re: State of the Gears
Not everything was well done, though: The Pyramid merger announcement was handled poorly. I'll discuss the future with Pyramid more thoroughly below. We discussed what we want to see for this year, and I think our goals are more than reasonable. We want to get 2.2 out shortly (originally, we were thinking before Pycon, but I'm not sure we can after my absence of the past couple months). We want to get 2.3 underway, and we have some pretty decent sized plans for 2.3, and more on that below as well. We also have some plans for the website, some updates we want to see happen. We also want to find ways to expand the development team. We also discussed our need for Python3 support, though we don't have a firm timeline for that. Finally, we discussed the need for us to standardize on a JavaScript widget toolkit. Our plans for 2.2 are as follows: We want to either make or integrate a Widget browser. We're looking to switch to ToscaWidgets 2 by default, since they're about to release a stable version. We want to reduce the number of packages we have to show in our PyPI, in particular by repoze.what-quickstart and repoze.what-pylons. We also want to merge in work by Chris Perkins to make Object Dispatch into an external package named Crank. Our plans for 2.3 are as follows: Major speed improvements, possibly some backward incompatibilities will be introduced. We're planning on removing the dependency on Pylons entirely in this branch. Possibly we're going to replace the repoze.what/repoze.who packages as well as the default AuthenticationAuthorization mechanism. Our directions of inquiry for Python3 are as follows: We're going to look at marrow as a possible replacement for Paste. The other option is to look at Pyramid's Paste Replacement. We'll also need to evaluate other libraries and modules, as not everything is supporting Python3, and we need to move forward soon. For the JavaScript toolkits, we need to evalute Bootstrap, jQuery UI, and even Dojo. We did not come to a final decision at the time of the meeting, though it seems like we're going to settle on Bootstrap, based on recent conversations on the mailing lists. For the Pyramid merger, most of us who are using TurboGears are happy with the direction things are going for TG. After discussion, we came to the consensus that the product built on top of Pyramid that provides a TG-like layer should not be called TG3, but rather Orion. We're also leaning towards not promoting it as the evolution of TurboGears. TG isn't perfect, but we're happy with it, and want to continue to extend it, improve it, and make it vibrant again. To: Trubogears2 steering committee/TG2 Core developers My goal of writing today is to convince TG2 core developers to reconsider their plans for not using pyramid, embrace the new changes in pylons(pyramid), and reconfirm the state of the union between turbogears2 and pylons project. Turbogears2 pylons backbone was a great success, it consolidated python web frameworks, and provided a bigger community to compete with others like django, ROR and was probably the perfect choice to develop web applications fast. Now 3 years later Turbogears2 (1K Downloads since 04/2012) is still strong but pylons (11K Downloads) have merged with repoze.bfg(3K Downloads) to create pyramid(14K Downloads since 05/2012), which merged the web frameworks even more and brought over some of zope/plone community with it. What these number mean for turbogears future is that if tg2 reconfirms their ties to pyramid, it might become one of the most powerfull contender to django (212K downloads). What are some pro's and cons with following pylons evolution: Pro: --Features that pyramid is capable of would work by default in turbogears, no rewrite of code would be required to take tg2 into python3 for example, take the speed improvements, etc... --All the components that were mentioned above from repoze.XXX would still be valid and would follow pyramid upgrades and no additional work would be required to get them working. --Any changes to Paste would already be done in pyramid. --Turbogears choice of most downloaded components as a default would bring over few users that have high learning curve because of pyramid default scaffolds selections. --More consolidation would mean more of most common packages would be available to users. -- Instead of splitting from pylons embrace the evolution of pylons would mean more users are reassured tg2 is the right choice to build on. Cons: -- Some work is required to replace pylons components with pyramid -- Some tg.ext would need to be updated to support new changes. -- Core developers would have to go a little outside of their comfort zone by not just being happy with current state of tg2 but to take it to the next level. -- Won't be able to design the new framework to replace pylons part, but rather will need to include
Re: [tg-trunk] Re: State of the Gears
This has already been discussed around an year ago, both in person, on HangOut and many other ways, and we came to an agreement that didn't prevent anyone from doing his own TurboGears like scaffold on Pyramid, it just didn't have to be called TurboGears. Orion was the suggested name at the time. Now I don't see any point in bringing it up again, especially considering that the 2.3 pylons less branch has been already under development for 6 months, is now able to serve TurboGears applications three times faster without any required change, works on Python3 and has 1/3 of the dependencies we previously had. That doesn't mean that TurboGears can't work with the Pyramid team, we are in 2012 and most of the web frameworks are now build by many independent modules that provide some kind of feature to the framework. We will continue to share WebOb, Baker, WebHelpers, most of the repoze stack and many other things. It's just a matter of would you like to replace 400 lines of custom code with a library thousands of lines big that won't do anything new and you will probably have to monkeypatch deeply like it happened with Pylons?. TurboGears already broke code of its past users too many times and doing it again would probably hurt the project a lot more than not having written on our homepage that we are whatever underlying framework based. On Sun, Jul 8, 2012 at 8:28 PM, Lukasz Szybalski szybal...@gmail.com wrote: My goal of writing today is to convince TG2 core developers to reconsider their plans for not using pyramid, embrace the new changes in pylons(pyramid), and reconfirm the state of the union between turbogears2 and pylons project. Turbogears2 pylons backbone was a great success, it consolidated python web frameworks, and provided a bigger community to compete with others like django, ROR and was probably the perfect choice to develop web applications fast. Now 3 years later Turbogears2 (1K Downloads since 04/2012) is still strong but pylons (11K Downloads) have merged with repoze.bfg(3K Downloads) to create pyramid(14K Downloads since 05/2012), which merged the web frameworks even more and brought over some of zope/plone community with it. What these number mean for turbogears future is that if tg2 reconfirms their ties to pyramid, it might become one of the most powerfull contender to django (212K downloads). What are some pro's and cons with following pylons evolution: Pro: --Features that pyramid is capable of would work by default in turbogears, no rewrite of code would be required to take tg2 into python3 for example, take the speed improvements, etc... --All the components that were mentioned above from repoze.XXX would still be valid and would follow pyramid upgrades and no additional work would be required to get them working. --Any changes to Paste would already be done in pyramid. --Turbogears choice of most downloaded components as a default would bring over few users that have high learning curve because of pyramid default scaffolds selections. --More consolidation would mean more of most common packages would be available to users. -- Instead of splitting from pylons embrace the evolution of pylons would mean more users are reassured tg2 is the right choice to build on. Cons: -- Some work is required to replace pylons components with pyramid -- Some tg.ext would need to be updated to support new changes. -- Core developers would have to go a little outside of their comfort zone by not just being happy with current state of tg2 but to take it to the next level. -- Won't be able to design the new framework to replace pylons part, but rather will need to include already written software. TG won't be perfect with pyramid at its core but I think a lot more users will be happy with it, and want to continue to extend it, improve it, and make it vibrant again. Would developers consider following the evolution of pylons and including pyramid into turbogears? Thank you, Lucas -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To view this discussion on the web visit https://groups.google.com/d/msg/turbogears-trunk/-/55ZqKLBol6wJ. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: State of the Gears
Am 08.07.2012 21:20, schrieb Alessandro Molina: Now I don't see any point in bringing it up again, especially considering that the 2.3 pylons less branch has been already under development for 6 months, is now able to serve TurboGears applications three times faster without any required change, works on Python3 and has 1/3 of the dependencies we previously had. That doesn't mean that TurboGears can't work with the Pyramid team, we are in 2012 and most of the web frameworks are now build by many independent modules that provide some kind of feature to the framework. We will continue to share WebOb, Baker, WebHelpers, most of the repoze stack and many other things. It's just a matter of would you like to replace 400 lines of custom code with a library thousands of lines big that won't do anything new and you will probably have to monkeypatch deeply like it happened with Pylons?. TurboGears already broke code of its past users too many times and doing it again would probably hurt the project a lot more than not having written on our homepage that we are whatever underlying framework based. Agree with all points. Actually Pyramid is not such a huge library, it's still pretty lightweight. Nevertheless, the core Pyramid docs is already a 700 pages PDF file. People would have to use a framework where they don't understand what's going on in the lower levels or they would have to read these 700 pages just to understand the lower levels. Also, if TG would make another radical change now, we would again come into the situation where people start asking shall I use TG2 now or shall I wait for when TG3 based on Pyramid appears, and start wondering whether they will be able to migrate their TG2 apps. And then, the documentation would need to be adapted again etc. Lastly, everything also depends on the time and energy the core developers have at hand, and that is very limited. Mark, who orginally came up with the plan of a merge, wasn't able to spend time for the project any more. Currently only Alessandro and Michael are actively working on the project. Maintaining what we currently and developing that slowly and carefully is already enough work. I think they're doing a good job, and I like that TG2 is moving more steadily now and less jumping around with new ideas and changes every other week. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: State of the Gears
There's no doubt that other frameworks are bigger, more widely used, and more popular. No argument from me of any sort. Arguing in favor of a merger by stating We have a better chance of taking down Django is not a useful argument, though, not for me. I don't devote the time I do to take down Django. I don't do it for money. I don't do it for fame. I don't even do it to help other projects improve, or reach any of those goals. I do it because I love TurboGears. This web framework is the first one I ever found that actually made *sense*. I'd tried others. I'd even written my own really bad one in PHP in the early 2000's. None of them ever felt wholly right, though. Always, some aspect was poorly done, or some piece always got in the way of my project, or the entire system just seemed designed to make easy tasks complex, and hard ones virtually impossible. TurboGears provides something that others have always seemed to lack: just the right amount of simplicity. When I go to work on a TurboGears project, I can navigate it easily. I can find and deal with the various pieces, and feel comfortable that I am actually finding what I need to find. When I need to make a change, I can feel comfortable that I am changing the right piece of code. TurboGears provides these things for me, and it makes coding with it into a joy. Arguing in favor a merger on the grounds that everybody can topple the Django beast will not sway me. I love what we have, and I feel that the future is bright. It's not an easy row to hoe, to be sure, but few things worth doing are. All of that said, I'll address the rest of the points, and reply to everybody. On Sun, Jul 8, 2012 at 2:28 PM, Lukasz Szybalski szybal...@gmail.com wrote: Assuming that we did the merger work, we would have some piece of code called TurboGears that is based on Pyramid. Keep that in mind for these responses. --Features that pyramid is capable of would work by default in turbogears, no rewrite of code would be required to take tg2 into python3 for example, take the speed improvements, etc... Unfortunately, this is not correct. We would be vulnerable to which specific version of Pyramid we coded against. If a benefit from Pyramid required changing the way we use an API, we could not gain that benefit until we updated the code. If a backwards incompatible change were made in Pyramid, we would have to update our code to fix it, or lock down which version of Pyramid we support. If we found a problem in Pyramid, we would have to rely on Pyramid to update before we could truly get it fixed. Furthermore, while Pyramid may be Python3 ready, we are not. Pyramid being ready or not has no bearing on whether our code is ready, and that's true regardless of anything else that may be going on. This pro has some benefits, to be sure, but it's not the bed of roses that is painted here. --All the components that were mentioned above from repoze.XXX would still be valid and would follow pyramid upgrades and no additional work would be required to get them working. The same problems and benefits as the previous item. --Any changes to Paste would already be done in pyramid. While this is true, since we're not at that point in our own development. As such, this item is not a consideration for us at this time. In future, maybe, but right now, no. --Turbogears choice of most downloaded components as a default would bring over few users that have high learning curve because of pyramid default scaffolds selections. Agreed on this point. This would help Pyramid adoption, definitely. --More consolidation would mean more of most common packages would be available to users. For consolidation, what I would actually look to provide is some way for modules to seamlessly make themselves available for multiple frameworks. For instance (and this may be a bad example), if we were to provide a webframework.model entrypoint, and all the frameworks were to honor it, then a given plugin could make it's model accessible without caring about who it's written for. That would allow for consolidation, without requiring that everybody join with a specific web framework or be invisible. -- Instead of splitting from pylons embrace the evolution of pylons would mean more users are reassured tg2 is the right choice to build on. Does it really? If someone is trying to make a choice, then wouldn't Built on Pyramid being on everybody's site be more of a vote for any users to go to Pyramid, instead? If the number of users mattered to me, this would actually be a detriment to TG, not a bonus. Cons: -- Some work is required to replace pylons components with pyramid An unknown amount of work for a benefit that may not materialize for the TG framework. That's a high risk proposition to me. This particular item is a bigger detriment than I feel you give credit for it being. -- Some tg.ext would need to be updated to support new changes. Actually, many of them would. For
