{curl 5.0 applet}
…
{curl 4.0, 5.0, 6.0 applet}
…
A thread on the Curl Developers Forum that is getting a lot of attention from the Curl community debates the merits of this versioning architecture. While a couple of developers argue that backward-compatibility is a must, Curl engineers argue that its customers actually prefer the versioning system it now supports and that its actually better to run concurrent RTEs than to design each new RTE to be backward compatible. The reasons for this, its argued, is that the application developers is assured that the applet will only be run - without modification - on the runtime it was designed for. It’s also argued that this gives the Curl engineers more flexibility, requires less effort, and creates less problems than trying to make each new version of Curl backward compatible.
Personally, I’m torn as to which is the appropriate solution. Although I work for Curl I always thought that backward compatibility was a necessary evil. The Java platform, which is the one I have the most experience in, has always attempted to be backward compatible which makes things easier for end-users but has, as I understand it, been a source of problems for Sun Engineers who must continue supporting older features of the language and platform despite the fact that those features might actually hinder evolution of the platform.
Is the Curl versioning architecture superior in terms of platform evolution or is it problematic? I’m beginning to see the logic in not explicitly supporting backward compatibility. It makes the most sense in the enterprise where IT departments seem to prefer that older programs keep running on a known versions rather than risking old programs on new platforms.
I’m interested in the opinions of InsideRIA readers. Is backward compatibility a critical requirement or can it be avoided in favor of more agile development of the platform?
Update: More information on Curl's backward compatibility story can be found on Curl's blog posting "Backward Compatibility and Curl"
If you're not supporting backward compatibility it says a couple of things to potential adopters:
1) Curl doesn't care about their user's investment
2) and/or Curl doesn't have any users
I'd be interested in the following:
- What size of user base does Curl have?
- What is Curl's market penetration?
- Why does Curl still have Flash on it's home page (Microsoft are guilty of using Flash for marketing as well. I suspect I know the response, but eating your own dog-food would be more appropriate)
- I have read claims (by yourself possibly) that Curl is more secure than Flex, I asked this question elsewhere and never got a response... how is Curl more secure than Flex?
Thanks in advance.
Regards,
Chris
1. If you upgrade a Drupal site, then your CMS content comes along for the ride flawlessly, but
2. Any templates / customizations might suddenly break and/or you will have to wait until those open-source teams update the "parts" to work in the latest version.
In the case of open-source I get this paradigm for a couple of reasons:
1. It makes for more versions of the core product faster, since you don't have to care about stuff outside the core.
2. It makes for an increasingly stable product, since you can break something that was functioning in order to fix it using a completely new approach (even if that new approach break everything else that connected with it.)
3. It allows the core to force everything to grow and refine itself to better the overall product by forcing change from the core, out!
As someone who has been working in development for more than a decade now, I have a few opinions about this that comes from my experience:
1. Sometimes I have regretted decisions I have made early on in a project and wished I could completely derail a segment of that work. In most situations, however, companies don't like this approach because it limits the future value of something without continued development.
2. I think that if you can be brave and invest in intelligently break version compatability for a good reasons early on, then this technique is OK. But I think that as a product matures, it should stabalize to the benefit of your product and it's community.
I would tolerrate a breaking version compatability technique for a while, but after a few "breaks" I think I would get a little fed up. You can have time to settle on the right approach, but I think you need to settle eventually.
]]>Mike
]]>We are not "guaranteeing" backward compatibility but choosing side-by-side runtimes by design to better support the needs of our enterprise customers. Backward compatibility is at best difficult to achieve and often results in major efforts by the enterprise to test production runtimes against new versions of a platform which provide little or no advantages to those specific applications. Side-by-side allows you to continue running your application without interruption while taking advantage of new features for new projects. The Curl runtime is 10 years mature and is the fastest in the RIA industry so we don't need to focus on performance as is the case for some other platforms - our enhancements are generally extension to the platform.
With regard to our customers base - its a lot larger than you think and probably much smaller than Flex. Although we are gaining ground quickly most our enterprise customers, well over 300 of them, are in Asia. I guess if you don't care about that market (you should!) than that may seem unimportant but that's the foundation on which we have built our operations.
The flash question is pretty obvious. We use flash for the same reason that Adobe, Microsoft and Sun Microsystems (all RIA vendors) use HTML - its an appropriate technology for mass consumers. Should Adobe make their entire site Flex? Should Microsoft use only Silverlight and avoid HTML? Obviously not.
We think Curl is better for the enterprise and a public web site is not an enterprise application.
I hope that answers your questions. Thanks for commenting on the article - the kind of feedback you provided helps a lot!
]]>