This blog is an archive. See our new blog at http://blog.mach-ii.com.

Some links may be outdated. Our Trac and SVN have moved:

Philosophy: Our decisions on what CFML engines we support

At cf.Objective() 2009 just a few weeks ago, I was asked why does Mach-II 1.6 support ColdFusion MX 7 since CF9 is so close.  I was kind of perplexed by the question to be honest, but without knowing some history it does seem like a strange decision.  So why does Mach-II 1.6.1 (the latest stable as of May 2009) which is the maintenance release for 1.6.0 support ColdFusion MX 7?  The answer is a simple one.  Planning for the 1.6 release cycle started in the December of 2007 and during our development cycle Adobe had barely released ColdFusion 8 (which was released on July 30, 2007).

We want to support everybody as far back as possible, but our normal rule of thumb is to support back two versions (or as far back as Adobe provides official support for in the case of ColdFusion).  However, our development cycle does not match up with the release cycle of the big three CFML engines and therefore our rule is not a hard and fast rule.  For instance, Mach-II 1.8 will still support ColdFusion MX 7.

I know people will say why not just drop support for 7? There are few points about that:

  • While ColdFusion 9 is coming, it's not here yet and not everybody will be able to upgrade immediately (economy / money). Plus, there are many people still on MX 7.
  • One of Mach-II biggest tenants since the inception of the project is backwards compatibility (BC) and we want people to use the framework as much as possible as long as they have a relatively recent version of a CFML engine.
  • Not all CFML engines support all features. This is actually something that most developers do not have to worry about because they write their applications to be deployed one favor of a CFML engine. Most developers just use one engine or another for developing their applications and don't really care about compatibility.
  • You cannot use this sexy new feature in the language.  What features in ColdFusion 8 does the framework itself need to leverage to new "cool" stuff that are not available in MX 7?

The last point is interesting one to make, because when use this as a rebuttle most people say stuff like:

  • You can't use onMissingMethod()
  • ColdFusion 8 is faster than MX 7
  • ColdFusion 8 has threading

Ok, good reasons for the needs of your application, but name a place in the Mach-II framework core that we need onMissingMethod()?  Maybe your application needs it, but Mach-II's features do not need it.  That point is more about your application's functionality.  The framework itself isn't missing stuff to "innovate" on.

Yes, ColdFusion 8 is faster, but that again is a need of your application.  Internal speedy for the sake of the framework core does not impact what features we can offer; it affects the application you might built on top of it.

The last point in regards to threading you might have gotten me a bit and yes, there a few place where threading would be nice in the framework, but it's not required.  In the end, we wrote a things called the thread adapter which allows us to run code in certain places threaded, but downgrades to serial processing if the engine doesn't support it.  Since it's all automatic, it's nothing you have to worry about -- you either have the ability granted to you application, but gracefully downgrades if you don't. You can read about how to use the threading adapter on our wiki if you are curious.

The main point is that the framework core code itself is not suffering from the lack of onMissingMethod, interfaces or anything other new features that CF8 or Railo or Open BD offers.  Actually, the framework core code itself is doing rather mundane things like shuffling data around mostly so you can develop your applications faster and do the fun stuff instead of pushing the form or url scopes about.  All the sexy stuff that your application does is stuff you write.

Lasly, Team Mach-II wants to support all the major CFML engines - ColdFusion, Railo and OpenBD (official support for Railo is coming soon).  Why would we want to do this?  Because we're cross CFML engine compatibility sadomasochists...not!  Because Mach-II should be able to run anywhere.  It should not be reason why you cannot not use Mach-II for you new application -- because you use an engine that we don't support.  If you have major CFML engine with a relatively recent version, we should support Mach-II on it.  Plus, you would not believe the amount of emails I receive about LylaCaptcha asking me if I support ColdFusion 5 and if I have any plans to support it (Lyla itself is a CFC that uses Java, none of which CF5 supports -- so it is a no go anyways).  So it goes to show you that there is wide variety of users using older versions.

Call us a stick in the mud for supporting the framework on "old" CFML engine versions.  I call it being pragmatic -- at the moment there isn't anything that one CFML engine offers in the terms of features that we absolutely need to implement sexy new feature K or Y yet.  Only good reasons are a compelling way to make good decisions otherwise it's just a decision for the sake of making a decision.

0 Trackbacks  |  Articles  |  Send
Posted 5/29/09 @ 4:00 AM by Peter J. Farrell