I'm shamelessly too intoxicatd to reply, but Ezra encapsulated my thoughts tonight.
When he said, Hivemind is about ego, I was silently applauding. I don't understand whey the Tpy community cannot talk to Rod and Jurgen and have an integration. Let's talk .Net and JEE. For hte past year I have been an onanist who has wicked fantacies of elcipse in lace while I slave away shackled to VS.net. The fundamental convepts behind tapestry are 1) not original. 2) not unique to a given language 3) highly productive HLS has done a jaw dropping awesome job of architecting T. But I never understood why spring could not be substituted in place of Hmind. Honestly I always thought Hmind was a case of ego. with much respect and kudos to HLS, I don't know why any implemtation of T, would need a particular DI or IoC container. T is a presentation layer framework. period. If I want to have a bunch of data services screamj out WDSL T. has no use. Well why would T. and Hmind be so married. Most A. projects with notable exceptions, do one thing, and one thing well. If HLS imagines a pure java impl of T. without Hmind, then that is great. I like orthoganality. I think competing with Pico, Spring and raw codw e is a mistake. Why can't we integrate with Spring....That's what my clients want.....Guaranteed. Seriously, If I mention Hivemind, people are out....' THe proxy we wrote is ok for small interdirectional transfers. Much mor eis needed in reality. On 7/29/06, Spencer Crissman <[EMAIL PROTECTED]> wrote:
Bingo. The issue isn't that having a Tap5 is important, for it is. There will always be a need to add new features and support new technologies as a framework expands. The issue I have is that every Tap release doesn't just add new abilities, it completely scraps the existing code. There are numerous reasons why this is a poor way of working. Specifically: 1) A framework's is by nature harder to learn than other technologies. This is because unlike learning a particular application, learning a single library, or learning just a class, a framework adds a great deal of complexity in order to be a more general purpose solution. This added complexity results in a steep learning curve, which requires a large investment of time on the part of its users in order to learn. The payoff, or return on that investment of time is the ability to leverage that knowledge on a variety of projects. By rewriting the entire framework with each release, that investment of time is destroyed. Developers barely have time to see a couple of projects through before they have to relearn the new way of doing things. This severely limits the returning value of the framework, and is very wasteful when it comes to developer time. 2) Specific to Tapestry, the framework is based around reusable components. The promise of the existance of these components is very powerful, and could be a source of as much value as the framework itself. By continually invalidating the component libraries that exist, we once again limit the ongoing value of the project. A component based framework ought to have a vibrant user community with a large variety of compnents that will work for a long time. I'm not seeing that happen with Tapestry, despite all its promise. 3) Having a framework that works only for a single snapshot in time may work for some companies that write an application and release it. But really, that is probably more suited to a client side application than a web framework. The reality is that most of the web applications developed in Tapestry 4 will need to be supported in place for a long time. And during that time, feature requests will come in that can only be implemented using the technologies made available in Tap5 or Tap6 or TapX. Developers need to know that when it comes time to add new features, the cost is proportionate to what they are adding. To add a small feature that uses some tiny subset of Tap5 features, I will have to rewrite the entire web application? Again, such a waste of time. 4) One powerful advantage that open source projects have is that there is so much expertise, and so many skilled individuals out there, that working together they should be able to view the project from many different sources, and see many different ways that the project can grow and take shape. This should add some level of flexibility to the projects. There should be some level of forethought from a variety of angles built into the code. The fact that every new release of Tapestry requires a rewrite makes me question just what is going on. Why can't a system be made to work without being so rigid and inflexible that it cannot be adapted in the future? We have so many patterns and so many well understood software design principles exactly to prevent having to do complete rewrites. That a project isn't able or isn't willing to use them for that purpose is worrying, to say the least. This is understandable for a new project, or a young project, but we're talking about version 5 now. 5! 5) Open source projects rely on contributions via mailing lists and/or wikis and tutorial websites to teach developers the ropes. Completely changing the way everything works in every release makes it hard to learn, hard to search for, and hard to establish best practices. You aren't just throwing out code when you scrap a framework, you are throwing out all the knowledge that has accumulated around it. As was mentioned elsewhere in this thread, this isn't a race. Do one thing, and do it well. If hivemind doesn't have the new features, get them done in that project, maintaining backwards compatibility, and then bring them to the Tapestry project for the next release. With so much waste in the world, why are we reinventing the wheel that was specifically reinvented for this same project so recently? In the end, for me, it boils down to this: We are a small company, and our small group of developers will be growing the applications we build over time. We have to look at both the current capabilities, and the future costs of the frameworks we select. While Tapestry's current capabilities are great, the future costs that it will incur if it continues along the path of constant rewrites are too great for us to invest in it. There are many users in the same boat. Why do none of the above points make any difference in the future path of Tapestry? I find it ironic that one of the stated goals on the Tapestry 5 IoC Introduction is "User Friendliness" when invalidating all their current knowledge and future upgrade paths for existing projects is about the least friendly thing anyone could manage to do to a developer. I hope the devs are listening, because this project has too much good potential to see it get a tarnished reputation over compatibility. On 7/28/06, Jason Dyer <[EMAIL PROTECTED]> wrote: > > Because, a company that has invested a year or more, developing an app is > probably going to want to use it for a little while. Over the lifetime of > an > enterprise app, it will undoubtedly need modification (both bug fixes and > added features.) > > When Tapestry 5 arrives, we can safely assume that Tapestry 4 development > will > stop fairly shortly thereafter (new features immediately, maybe bug fixing > will go on for a year or two, but that's nothing compared to the lifetime > of > a large app.) Then there's the fact that, right now it's difficult enough > to > find people with skill in T4, but in a couple of years it'll be > impossible, > because most people will have moved on to T5... > > If the migration to T5 requires what basically amounts to a rewrite and T4 > is > no longer maintainable, then the 'powers that be' at said company are > going > to be a little irate that they've invested so much time/money into > something > that ultimately didn't last very long. In fact, they'll probably be > looking > for heads to roll... > >
