It's Time To Standardize CFML
March 02 2007 by 
Andrew Powell
Up front, I am not opposed to other CFML engines. Yes, I use only ColdFusion in production environments, but I have played around a with BlueDragon and other CFML engines. That being said, I feel that we need a common CFML base from which to base all CFML engines; a CFML core, if you will.
One thing I have noticed is that you have tags that do not behave the same across platforms. A prime example of this is CFDOCUMENT on ColdFusion vs. BlueDragon. Blue Dragon will create raster documents, but not FlashPaper, and ColdFusion will perform inversely. This is not a good thing. I understand the marketing pitch of "Our tag does something theirs doesn't.", but this is nuts. As developers, we want a tag to perform the same no matter which platform is the deployment target.
We are at a point in the life of CFML, as a language, where there needs to be some sort of standardization to the CFML language. How will a CFDOCUMENT tag act? How will a CFCOMPONENT tag act? We should be at a point where CFCOMPONENT will work the same no matter what platform you are on. Most developers don't want to have to consider: "Will this run on ColdFusion AND BlueDragon?". We want it to just work.
A harmonious approach would be to say "Let's have a conference and sort through it." Fact of the matter is, that's just not going to happen.
Adobe is the 800 lb. gorilla in the room on this issue. As much as we would like to laud New Atlanta for what they've done with their CFML engine, Adobe is still, and will continue to be, the market leader. When people think CFML, they think ColdFusion; and when they think ColdFusion, they think Adobe (or Macromedia, or Allaire, but that's another topic).
What does this mean for standardization? From a business standpoint, it means that all other CFML engines need to, at least, fully support the market leader's implementation. Beyond that, the "unofficial" CFML engines can add new functionality (i.e. CFTHREAD). If it's deemed viable, then they can see it assimilated into ColdFusion (as has happened with CFTHREAD).
Sure, other CFML engines say that they support 90% + of the ColdFusion implementation of CFML tags and functions. What about that other percentage that isn't supported? It's true with any CFML engine that isn't "the official product": If you don't support all of Adobe's functionality, you are not compatible with ColdFusion. Plain and simple. Partial support is not an option here. In standards, it's an all or nothing game.
Is Adobe going to open up CFML as language? Why should they give away the market? It's bad business to do so. All they can do is innovate, and hope that other CFML engine vendors can keep up.
Under Allaire, Macromedia, and now Adobe, ColdFusion and CFML have flourished. They have been good stewards of the CFML language. I see no reason to let them not lead the way on CFML standards going forward.
Until the other CFML engines come in line, there is still going to be a choice: "What CFML engine am I developing for?" Most likely, the answer is going to be ColdFusion. However, if any of the other CFML engines can fully support Adobe's CFML implementation, that question becomes much more complicated. We are not to that point yet. One day, however, we may be at that point where the decision of which platform on which to develop becomes a bit more difficult to answer.
Posted in BlueDragon | ColdFusion | Adobe | 
18 comments
Mar 3, 2007 at 12:00 AM <p>I think the open source projects are good for the market and especially the community. The developers behind these projects are doing their best to meet the standard that is defined by Adobe. These projects foster the increasing adoption of ColdFusion as a language and expand the community.</p>
<p>However, it's not fair to name Adobe as owner of the standard based solely on market share. There are a number of talented people at Adobe who have spent more than a decade innovating ColdFusion and building a community. I think their unmatched devotion and creativity has _earned_ them the right to define the standard.</p>
<p>Regardless of the spin you’ll hear from New Atlanta, they created BlueDragon to make money off of others’ hard work and ingenuity. Their claims that they are ‘helping’ the language/community is wrong. Every version of ColdFusion released by Allaire/Macromedia/Adobe has been a direct result of community input. There was never a need for a competitor to ‘force’ innovation. Furthermore, New Atlanta’s attempt to justify their position in the market as “we’re here to support the community in case Macromedia/Adobe discontinues ColdFusion” is nothing short of fear politics. Due to the reasons listed above, ColdFusion has always been a healthy, profitable and successful product. Its success built Allaire and its growth was unparallel at Macromedia when New Atlanta decided to ‘help the community’.</p>
<p>Although I think free open source CFML engines are good for the community, I don’t think ‘cheaper’ engines are. Between ColdFusion Standard and Enterprise, there just isn’t a market to support a cheap knockoff. Struggling from a lack of profits in the ‘catch up market’, New Atlanta is doing whatever it can to make a buck (like selling out to Microsoft!). Their latest business model is based on anticipating the future of CFML. They are trying to guess at future functionality and tags like in hopes that getting to market before Adobe may turn their luck around. Unfortunately, all they have managed to do is bastardize the language. It’s highly unlikely that their first-to-market product (by less than a year) will have any effect on the next major release of ColdFusion. After all, the design and development of Scorpio started over two years ago. In the end, any overlaps in functionality will most likely have different interfaces.</p>
<p>Sometimes I think New Atlanta couldn’t possibly harm ColdFusion more than it already has. Not only did they sell out to Microsoft and help one of the biggest websites in the world migrate _away_ from ColdFusion and on to .NET. Their latest grasp for dollars is undermining the language itself.</p>
<p>You want a real easy way to standardize the language? Stop supporting BlueDragon.</p>
Mar 3, 2007 at 12:00 AM <p>forget the theoretical for a monent, for what practial reason do you want this? what problems have you come across (in all reality) that stems from this?</p>
<p>is it developer skills that a new developer coming into a dev house using BD has to learn this? if so, wouldn't that be part of the developer induction, mentoring, etc?</p>
<p>or is it for code portability? it won't run on everyone's version of their CFML system?</p>
<p>welcome to real life. </p>
<p>how many times have you grabbed a java sourceforge project to be stumped with the wrong libraries or sorting out dependancies just to get the wretched thing to compile? </p>
<p>even in the .NET world you still have versioning to worry about (and best'o'luck moving your VB6 code).</p>
<p>how about different C libraries? try compiling your Borland code elsewhere.</p>
<p>and even API's within apps: Blackboard LMS inconsistancies between v6 and v7.</p>
<p>with all due respect sir, build a bridge - get over it. It just ain't gonna happen and I'm fearful of such harmoginisation because it will stifle advancement.</p>
Mar 3, 2007 at 12:00 AM <p>With respect to compatability across platforms, Adobe (and historical incarnations) can't even manage code compatiability between their own versions. Each new release breaks something in the previous one. Most developers don't notice it, but those of us that are building as close a compability as possible do. One of the reasons that Adobe don't officially submit CFML as a langauge to a standards body is quite simple -- they would be struggling to match it themselves.</p>
<p>As for the point "Is Adobe going to open up CFML as language?", they already have. CFML is a text based language, it is already open. You do not need any special reader or need any special algorithms to read it. What more do you need?</p>
<p>Competition is good for any product, CFML included. BlueDragon has opened up the market for others to exist. This gives the customer more choice, and ultimately raises the whole CFML sea level. If you were to really look at the market positioning of each of the CFML engines it is quite clear they are not taking a lot of food out of each others mouths; they are all targeting a different sector that isn't serviced by the others. This is what choice brings.</p>
<p>Competitors validate there is a market. It amuses me how quick we all forget history. On each of the buyouts from the Allaire days, the big question that was on everyones lips was "will ColdFusion survive?". None of the other products where in question, except that one. Ask any CFML User Group leader about how much support they got. Alternatives like BlueDragon proved there was indeed a market for CFML and it was still worth investing in. Infact you could argue that as of today, CFML as a language has never enjoyed greater success or attention.</p>
<p>In many respects though, this is all somewhat moot. The majority of projects never get ported from one engine to another. Even in the Java world, a JBoss shop would only go to say WebLogic or Websphere kicking and screaming as it usually involves a huge amount of porting and code rewrite (and this is for a specification, J2EE, that is very well defined).</p>
<p>Presenting CFML to an official language body while a nice idea, won't solve as many problems as you may think. As J2EE (and other standards) have proved, you can write down what is suppose to happen in a given set of circumstances, but that rarely translates to what WILL happen.</p>
<p>Viva CFML!</p>
Mar 3, 2007 at 12:00 AM <p>@Adrock:</p>
<p>"Struggling from a lack of profits" would be an inaccurate characterization of New Atlanta or BlueDragon. In 2006, New Atlanta enjoyed it highest overall company revenue and profits, and highest BlueDragon product-specific revenue and profits since BlueDragon was introduced in 2002. Our business model is working quite well, and we have every indication that revenue and profits will continue to grow strongly with the upcoming release of BlueDragon 7.0. Clearly there are many people who like what we're doing and are showing their support in the way that counts the most.</p>
Mar 3, 2007 at 12:00 AM <p>Sure, there's an argument for this but I can't see it ever happening. It's not just the language that could hamper compatibility but also the technology. e.g. if I move a CFMX app over to BD.NET then none of the Java CFX tags will work.</p>
<p>Imagine if one CF company said to the CFML committee that they've got a new CF tag (imagine something really amazing) then the others may object to the new tag because it would take them 18 months to bring it to market themselves - assuming they have the resource or the ability to license it if it incorporates 3td party technology.</p>
<p>I think the players know they should try to stick to the same tags and syntax, but when one of them creates a new tag/function they're actually making a language decision that the others are expected to follow. Adobe could have used CFASYNC instead of copying CFTHREAD from NA, so hats off to them for not trying to make things difficult for the community. If you move from an Oracle to MS SQL database then you can't expect the SQL to work without some modifications. The same should be expected of moving between CFML engines.</p>
<p>BTW, this captcha is really hard to input correctly! Attempt #4.</p>
Mar 3, 2007 at 12:00 AM <p>Captcha has been simplified.</p>
Mar 3, 2007 at 12:00 AM <p>Bottom line is this:</p>
<p>I want a core of CFML that is standard across all platforms. Beyond that, let the different engine vendors innovate, but that core remains common. What that core is, is up for debate.</p>
Mar 3, 2007 at 12:00 AM <p>I've been barking up this tree for a while now. I use railo at home, and Bluedragon.net at work, and I understand your frustration about tags and attributes being slightly different.</p>
<p>The solution is quite simple: There needs to be a CFML governing board to dictate a standard set of tags and functions and their behavior. So we would have CFML standard 1.0, which would support the following tags and functions...</p>
<p>If you're new atlanta and you want to make CFTHREAD, good jobm and it can be proposed for the next standard version of CFML. Adobe wants to make a Flex tag, great, and they can propose it for the next standard. Or not, if you view a tag as a competitive advantage, you're welcome to keep it.</p>
<p>Now, heres where this would come in handy. When the new version of Mach II comes out, or any other open source project, and even any commercial product, it will say CFML 1.0 STANDARD CERTIFIED. Then we will all know what to expect, and if it will work on our systems. This will also be a big help for the developers writing the code, because they will know exactly how their programs will behave.</p>
Mar 3, 2007 at 12:00 AM <p>RE: "I want a core of CFML that is standard across all platforms. Beyond that, let the different engine vendors innovate, but that core remains common. What that core is, is up for debate."</p>
<p>I'd argue that we're already there (at least as far as BD and CFMX are concerned--I don't know enough about the other CFML engines to comment). I'd argue that the "90%+" compatibility that you don't think is good enough, in fact *is* good enough and already represents the "core" that you're looking for. I'd disagree with the view in your original post that "it's an all or nothing game" and that the "all" is defined by Adobe CFMX.</p>
<p>There are simply too many marginal features in CFMX that vast majority of developers simply don't care about (CFIMPORT of JSP taglibs, anyone?). It's unreasonable to saddle BD (or Railo, or any other CFML engine) with the burden of matching every little feature of CFMX before we can be called "compatible" and before we'd be allowed to innovate by adding our own new features, which is how I read your original blog post.</p>
<p>Ultimately, the market is going to decide. All CFML server vendors are in this game to make money, and are going to implement the features they think their customers want to pay for.</p>
Mar 3, 2007 at 12:00 AM <p>For the most part, I can do everything I need to in bluedragon that I can with CFMX, and almost everything I need to do in Railo.</p>
<p>Vince is right though about adobe deciding whats core and whats not. Thats why I like the idea of a CFML standards board. That way each vendor would know what was going to be considered "standard" in the next release, and could work on the features.</p>
<p>This wouldnt affect vendors ability to innovate at all (like flex, if you want that), but for features that we all know are coming (CFTHREAD), it would atleast standardize the attributes.</p>
<p>Imagine how ridiculous it would be for BD to have completely different attributes for CFTHREAD, adobe to have their own set, and railo to have yet another one.</p>
<p>It would be ridiculous. Vince, how does New Atlanta feel about some sort of CFML standards board?</p>
<p>Are there any disadvantages that I am overlooking?</p>
Mar 3, 2007 at 12:00 AM <p>I must take issue with some of the comments fro other posters above with regard to compatibility between CF versions. </p>
<p>As the person responsible if things break between CF versions, I can tell you that we have (proudly) been able to maintain near 100% compatibility back through previous versions. The now 36,000+ test (and growing) automated CFML test suite and the monster suite of manually run regression tests helps ensure this is the case.</p>
<p>Clone CFML engine makers would be happy to have you believe that CFML compatibility is a really “fluffy” thing at best, that‘s pretty much amorphous, and it’s quite normal to have serious compatibility problems.</p>
<p>In one test recently internally, a well known copycat engine failed nearly 75% of the full test suite, and even the portion that passed had to be run in little bits, to keep the engine from dying, hanging, running out of memory or going into a mysterious infinite loop of some kind… </p>
<p>We built of that test suite with team of a QA engineers numbering close to 40 over the course of 2+ years, and it’s been built up to match new functionality every release since. Do the math and you realize just how seriously we’ve invested in compatability.</p>
<p>We’re one of the only major software companies that I know that believes so stringly in the 1:1 Developer-to-QA engineer ratio (outside of Microsoft), and I hold firm that nobody takes product quality or compatibility issues more seriously than we do. Many, many, government agencies at all levels of government run on CF, for example, and I’d be remiss if I took their trust in us to provide compatible software any less fanatically than we do around here. Ad we are fanatical about compatibility, innovation and delivering kick-features that make them look like heroes.</p>
<p> </p>
<p>Our automated test suite, in fact, is roughly 6X the size of Sun's J2EE CTS suite required to certify that a J2EE server is “J2EE compatible”, BTW. There may be very small outside test cases someone can point to where we missed something, but we try really, really, really, really hard to make sure those cases are very few and far between.</p>
<p>Damon</p>
Mar 3, 2007 at 12:00 AM <p>RE: "Imagine how ridiculous it would be for BD to have completely different attributes for CFTHREAD, adobe to have their own set, and railo to have yet another one."</p>
<p>Well, that's already the the case in a big way, I can confirm. We dind't have any choice. After consulting with customers, building umpteem apps, reviewng and hashing out all the possible usage scenarios internally, testing extensively and finding gotcha's in a bunch of different areas, as is the case any ytime we build a new piece of functionality, we realized we hadb't finished the job, and needed further changes to make a feature that was powereful, flexible, intuitive and easy to use by the majority of our user base. Just wrapping underlying functionality doesn't do anyone any favors, least of all our user base, and we have to live with our deicisions for years to come, so we need to flush out every feature till it's finally a feature that's well thought out, tuned, simplified and worthy of the ColdFusion name.</p>
<p>That process, unfortunately, causes changes, but we have to do what's right by our customers. </p>
<p>EVERY feature in Scorpio must bear the battle scars of a 3.0 feature or it'sn ot shipping on my watch.</p>
<p>Damon</p>
Mar 4, 2007 at 12:00 AM <p>RE: "I want a core of CFML that is standard across all platforms. ..."</p>
<p>you still haven't answered *why* you want this....</p>
<p> code portability?</p>
<p> developer skills (not knowing the differences)?</p>
<p>sure the work-arounds are inconvienant, but considering the situation, not insurmountabe...</p>
Mar 4, 2007 at 12:00 AM <p>The "why" of the matter is that there a number of open source projects that I am either involved in, or use, that have to constantly be modified to work across platforms (MachBug, MachBug, etc.). IF we could certify an app as CFML 1.0 compliant, then we wouldn't have to worry about changes for a version on ColdFusion vs. BlueDragon.</p>
Mar 4, 2007 at 12:00 AM <p>Hi Andy,</p>
<p>I think we've developed a good reputation for working with open source CFML projects (Mach II, Fusebox, BlogCFC, Farcry, etc.) to make sure they work on BlueDragon without requiring any modifications. So when you come across a compatibility issue with BD, please let us know and we'll fix it. In some cases, where there are features BD doesn't support (such as the CFMX ServiceFactory), we've provided CFML code to the open source projects for compatibility with BD.</p>
Mar 5, 2007 at 12:00 AM <p>Andrew - create a spreadsheet of all the tags/attributes/functions in CFMX/BD/Railo/etc and then identify all the ones that are implemented consistantly on at least three of the engines.</p>
<p>Declare those as CFML 1.0, and all others as extensions, and then supply that list to the engine makers and encourage them all to at least support the core, and consider implementing the extensions also (which could then go towards CFML 1.1)</p>
<p>:)</p>
Mar 5, 2007 at 12:00 AM <p>>> That process, unfortunately, causes changes, but we have to do what's right by our customers.</p>
<p>Damon, I am one of your customers, and I think you have misunderstood what I, and many other CF developers are looking for.</p>
<p>First of all, CF is a great product, and no one is debating that, or the incredible amount of hard work that you and the rest of the team has put into the product.</p>
<p>That being said, if i develop a product, or work on an open source project, it is quite annoying to have to make lots of little adaptations to deal with the growing number of CFML engines.</p>
<p>So, the way I see it, Adobe has two choices.</p>
<p>1) As the leader in CF, they can advocate a standard set of CFML functions, tags and attributes, and setup some sort of commitee to work with ALL of the CFML engine providers to at least offer everyone the chance of interoperability.</p>
<p>or</p>
<p>2) Refuse to work with BD/Railo/etc, and watch the language fork.</p>
<p>I am quite afraid that the 2nd trend might be more likely, and that would be very, very bad for coldfusion as a language.</p>
<p>The 1st alternative, I believe, would play out like this. A few knockoff engines would flourish, BD and CF would continue to grow. The free version of Railo and maybe the smith project (or even ignite fusion) would bring in lots of new developers who needed a cheap way to work on small projects or starting projects. CF and BD would continue to be options for larger scale deployments, and the total market would continue to expand.</p>
<p>Or fork it, and I'll go learn PHP. But I hate PHP, please don't make me do it.</p>
Mar 5, 2007 at 12:00 AM <p>macromedia were fools to allow anyone to grab hold of the word cfml and claim that anyone could have a cfml engine. coldfusion is coldfusion and cfml is as much coldfusion as the engine is. all the others are just using some marketting hype to say that they're using cfml for their language while skipping over the fact that its the coldfusion markup language. bluedragon should not claim to be coldfusion by saying they're using cfml while ignoring the coldfusion in the name. the same goes for ralio, coral, ignite and the rest. if you want to say your using cfml than follow cfml, not your own flavor. it seems obvious to me.</p>