Well, here is one nice blog entry about frameworks and backwards compatibility:
http://www.weiqigao.com/blog/2006/07/24/software_development_the_abstraction_dilemma.html On 7/29/06, Daniel Honig <[EMAIL PROTECTED]> wrote:
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... > > > > > >
-- Cumprimentos, Rui Pacheco
