A thought for ColdFusion 10

2009 December 17
tags:
by Big Mad Kev

With all this talk of what people want to see in ColdFusion 10, one thing I brought up at Scotch on the Rocks 2008 in the ColdFusion Bird of a Feather session; was an idea taken from the Flash Player team, where they introduced the Adobe Virtual Machine 2 into the Flash Player along side the Adobe Virtual Machine 1.

  • AVM1 allows the Flash Player to run ActionScript 1 & 2 applications.
  • AVM2 allows the Flash Player to run ActionScript 3 applications.

This gives the Flash Player the backwards compatibility it needs, to stay in the market place. Yet Adobe put a line in the sand, with AVM2 and ActionScript 3. Basically yes AS1&2 were great but they had their limitations and so AS3 was a total rewrite, and this has given us the Flash Platform as we see it today.

As there are two AVM's they can't directly talk so a AS3 application can't directly interface with AS2 code; there are work arounds but nothing that allows this cleanly.

So why do I bring this up with ColdFusion, well the big thing for ColdFusion has been the ability for backwards compatibility with each release. This is cool in some respects but in others can limit the platform going forward. For example the Apache AXIS can't be easily upgraded to the latest release, mainly because it was a total rewrite from the version used in ColdFusion.

So why not have an option within the CF Administrator where you can choose to use "Classic ColdFusion" or "ColdFusion X" which of course will need a restart just to clarify. 

There are of course people who will have an existing Application that they will upgrade to the latest version of ColdFusion where the "Classic ColdFusion" mode will ensure their application runs as it did, and have access to the new features. 

Then you will have the group of people who will be starting a Brand New project, who can enable Coldfusion to run in "ColdFusion X" mode. This would give them access to all the new fancy stuff that this approach would give. 

"ColdFusion X" wouldn't need to worry about the backwards compatibility, so would mean that the whole CFC / OOP issues that people hit with "Classic ColdFusion" would be gone, and other niggles like the PDF engine could be changed. As well as how the Java byte is generated and stored would also be changed.

I know this would also cause issues from a ColdFusion engineering resource point of view as a new feature for CF10 in the new engine would need to be ported back to the standard, but I guess you could have some sort of proxy so its only written once.

This of course would mean a split in the Community, and I know with most posts like this in our great community it will bring out a mass debate; but we have to remember that ASP guys have gone though this with Classic ASP and ASP.Net then you also have the python guys with the new Python 3000 being almost a total rewrite. As so did the ActionScript guys; so we wouldn't be alone, but I feel it will give ColdFusion a new base line to jump from and move forward.

It would be a rewrite of the platform as such, but more how the engine would run. The language would still be the same, with the addition of the new tags. 

I think this would open a lot more doors to what ColdFusion can offer going forward, some of which I will blog over the next few days.

An interesting idea I think non-the least. 

| View count: 721
5 Responses leave one →
  1. Brian Rinaldi
    Brian Rinaldi PERMALINK
    Dec 17, 2009 at 3:13 PM

    I suppose this type of idea could apply to the Flash Forms as well. My understanding is that the reason this hasn't been updated is due to backwards compatibility too (since its Flex 1.5/AS2) because all existing Flash Form based apps would essentially break. A negative is that this sounds like "compatibility mode" in IE8...and any idea taken from IE must inherently suck.

  1. Sam Farmer
    Sam Farmer PERMALINK
    Dec 17, 2009 at 5:05 PM

    Interesting idea but I think it might be something that needs to be handled at the tag level with a version attribute(?). While those starting on new apps would probably only use the new version there could well be a use for having both the old and the new within an app. Lets say cfdocument gets updated and has two versions. Even with a new app there may be some old piece of code that needs to run and setting version=1 works for that but the rest of the cfdocument work all uses version=2.

  1. Gary Fenton
    Gary Fenton PERMALINK
    Dec 17, 2009 at 5:45 PM

    Hi Kev. What you're proposing would mean a CF server couldn't run both a CF8 app and a newly coded CF X app simultaneously on the same server? I think your proposal for compatibility is, erm, mad. :-) It should either allow mixed apps to run at the same time (like how IIS allows classic ASP and .NET to run simultaneously) or you forget about compatibility altogether. If you have a CF7/8/9 app then you should continue to use your current CF server version if CF X doesn't allow older apps to run *and* make use of new CF X features. If Adobe aren't going to make new CF X features that would work with pre-CF X apps then there's no point in buying CF X and running it in compatibility mode. And attempting a backward compatibility mode in a future CF release would consume a lot of resource that could instead be used on building new features to make CF an even more amazingly appealing platform for new and old developers, and businesses too. I don't immediately see what's wrong with stopping support for pre-CF X apps running on CF X. I'm sure there are good arguments but they have to be weighed up against the benefits of not guaranteeing compatibility. Since most businesses are now virtualising it's not too expensive to create a new VM so you can carry on running your old CF apps on one VM and install CF X on a new VM for your new apps. Microsoft Windows Datacenter Edition allows you to install an unlimited number of Windows VMs under Hyper-V. I think Enterprise Edition allows 8. My final point is based on a question. How different do you imagine CFML on CF X being? If the syntax is mostly the same and tags aren't dropped in favour of cfscript, actionscript or ECMAscript, then there's a case for a good CFML compatability advisor app being written with line by line advice on how to modify old code to work on CF X. And I'm sure blogs and tutorials would help people upgrade their code if they have reason to move onto the CF X platform. Kev, if you can give examples of how you imagine future CF code would look like then it would be really interesting to see.

  1. Terry Galvin
    Terry Galvin PERMALINK
    Jan 6, 2010 at 6:41 PM

    I have a question I hope you and/or your readers can help answer. We have an intranet written with CF version 3 and need to move it to a new, sturdier, studlier, more reliable server. I'm assuming that would require buying the latest version of CF, but our concern is whether the code would still work. It's on a 486 machine running Windows 95, Access 95 and Apache, but I'm not sure which version of the latter. Any thoughts on what we'd need to do to save us rewriting the whole site would be very much appreciated. Thanks for any help you can give.

  1. Gary Fenton
    Gary Fenton PERMALINK
    Jan 6, 2010 at 8:19 PM

    Terry, will you be upgrading your server? There's no point upgrading CF if you're not improving the hardware and OS at the same time. It's impossible to say if your CF3 app will run on CF9 without inspecting the code. There's a fairly good chance it will run since the CFML language itself hasn't changed much (but it has grown with dozens of new tags and functions and techniques). Some tags and functions have since been depreciated and best practice has certainly changed since 1997 when I think CF3 was released. Crikey, that's 13 years ago! Why not download a trial of CF9 and test your app for yourself? That's the only way you'll know if it will run or not. If it doesn't then it shouldn't take any more than a couple of hours to fix it.

Leave a Reply