[Just to get out of work for a minute; not as a direct response to anybody.]
Personally at this point I'm not sure I care about (small) incompatibilities between CF5 and BD. I've been working with CF since version 1.5. Due to circumstances (my location and the fact my company was an early adopter) I've been able to watch ColdFusion/CFML (and its people) grow with some intimacy. CFML began as a handful of tags (six or seven) and with each major version added new functionality - extending, but in some cases changing, the language. Flash forward six years and we're here today discussing incompatibilities between two CFML products. However any practical discussion really should consider four (at least) products: 1) CF 4.5 is still is widespread use among larger shops. In general enterprises are looking for a 2-5 year life cycle for products. I honestly have yet to see a large company use anything but 4.5 (unfortunately for use the move to .NET and "Pure" Java has killed that for most - I personally will not be using CF at the office within a year the new "enterprise standard" being pure WebSphere development). 2) CF 5.0 is, for many, the stopping point and they have no plans to upgrade (or worse have attempted to upgrade and been forced to downgrade). It's fast, capable, and (most importantly for some) is still C++ and some runs their COM infrastructure components like MX can't. 3) Blue Dragon is a tempting solution for many reasons. It's "almost there" in terms of what most people do most of the time and although still a bit rough on the edges it's cost and deployment flexibility are very attractive. For my part it's also done more to popularize the idea of CFML as a language-not-a-platform than anything else. 4) CFMX is the future, the new baby, and 400-pound gorilla all rolled into one. The switch in platform (C++ to Java) was rough (and continues to be rough) for many, but its development and deployment benefits are obvious. MM is being (rightfully so) aggressive with its pricing (as small shops are the bread and butter of CF). So, from my vantage, we're seeing a clear fragmentation of our support and development market. We have large sections of our community being left behind and a growing section taking off in a new direction. This can be a good or a bad thing, but the short-term results are most likely going to be confusion and further enterprise apathy to the product. I fear that these issues will, in that they draw lines in the sand within the ColdFusion community, serve more to marginalize CFML than promote it. My opinion only, of course, but I feel it's an educated one. Macromedia should, I feel, finally spend the time to publish an actual specification for CFML (I think that CF has some great docs, but no specs that I've ever seen). I feel that this will not only allow others (like NA) to produce more compatible products but also improve the quality of CF itself. A centralized, well-maintained repository of how things should work can only be good for all involved. I'm not saying that they have to submit it as a standard (or, like Sun, declare themselves a standards body) but they should at least publish the geek bible. (They probably already have this in one form or another). (The "extras" can be seen as vendor specific additions: CFSEARCH, CFCHART, etc. The core language will be just that - with additional services taking center stage.) I feel very strongly that they should (with this specification) version CFML differently than CF. We should be able to understand that CFMX supports CFML 6.0 but that RedSky supports CFML 6.1. ColdFusion 4.5sp2 introduced new features: perhaps CF 4.5sp2 supports CFML 4.7. This will allow people to produce to very specific targets with supporting products, CFML applications and alternative language engines. I will not longer have to say "my app works in CF 5.0, CFMX and Bluedragon." I could say "My app conforms to CFML 5.1" which implies that. (And yes, I realize that the real world doesn't work quite that nicely. But, as for more languages, it's a goal worth aiming for.) We should be able to track bugs as they relate to the CFML specification. We can make definitive "should" (should act like this, should work like this, etc) statements for HTML, CSS, JavaScript, Java, etc. But with CF we're left with ambiguous claims of "compatibility" simply because we can only compare implementations, not specifications. CF is great - I think the best web tool ever, but it's continually seen as a marginal, proprietary product. In fact it's very often seen as a toy. I think that a formalization of CFML in the shape of a true, managed specification could help to change that image. Okay... that wasted an hour. Jim Davis President, http://www.depressedpress.com Webmaster, http://www.firstnight.org Webmaster, http://www.cfAdvocacy.org Senior Consultant, http://www.metlife.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
