"Howard Lewis Ship" <[EMAIL PROTECTED]> wrote on 01/08/2006 17:34:47:
<snip/> I tend to agree with most of what you said. > The central issue is backwards compatibility. As the upgrade from 2 to > 3 to 4 has shown, adding new features to Tapestry often breaks > existing code. This is a reaction to the relationship between the > framework code, and the application code. The fact that application > classes extend framework classes means that virtually any change to > the framework classes exposes client code to incompatibilities. Yep, this is the key issue at stake, and in fact it also appears to manifest itself as unnecessary inflexibility and constraints on component development. Changing this is a clear benefit, no doubt about it. > I've forced people to choke down the poison pill in little stages, > from 2 to 3 to 4. I don't expect that to happen once 5 is out ... the > annotation-based APIs are wonderfully flexible and adaptive even when > the framework is changed. That is a welcome positive message. > My goal is not to beat JSF, but to give Java developers a compelling > reason to stay on Java and not jump over to Ruby on Rails. That's a > tall order. With all due respect the way you need to go about that is to capitalise on the loyalty of your existing users, support us in achieveing our sucesses with Tapestry and we'll promote your project, no question. I don't underestimate the effort required to provide a migration path, but neither should you underestimate the value of retaining your existing users. The two features of Tapestry which really sell it into a commercial enterprise are 1) reuse and 2) the excellent separation of concerns between HTML & functional programing. To have no upgrade path at all would be to remove 1 as a benefit for existing users. I'm pretty sure that people will step up and contribute to an effort to provide backwards compatibility and upgrade tools, there is clear self-interest there to motivate us, but only if we think you guys really buy into the nesessity of it, and can convince us that it will be a once-and-final big-bang. Otherwise JSF, ruby on rails, even Oracle ADF, or any damn thing out there, will be seen as no more of risk or an effort to move to than sticking with Tapestry as a strategic choice will be. We have made the strategic decision to use Tapestry please don't make me change it. Those of us who have a broader view of product selection than technical excellence alone, we have to take into account the cost of ownership, will be hard pressed to continue to justify our decision if we don't have some kind of assurance that this really is a final one-off cost. Your earlier statement goes some way towards that I'm glad to say. Brian McCallister gave a great presentation on "managing open source" at ApacheconEU 05, (slide are here [1]) one of the key messages he made, and which is reinforced by the principles of schemes like CMMi and ISO9000 is that evaluation of OSS by commercial users must take into account the predictability & stability of the project and the ease of engagement with the community. Clearly documented roadmaps and statements of intent, and support for user-led initiatives are whats needed now if you want to pass those tests. Get behind and promote an effort to provide a migration path, no one expects you to do all of the work just to promote it, set out and end-of-life timeline for Tap3 and 4, document your decisions and I'm sure we'll stay with the programme. d. [1] http://www.chariotsolutions.com/slides/apachecon_managing_oss.pdf ******************************************************************************************************* The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient please delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ******************************************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
