Jim this is a great email with some very well thought through points ("My
app conforms to CFML 5.1") love that thought. Just want to throw a viewpoint
in here; we have been working with a large Enterprise level IBM Shop for the
past 2.5 years or so. They are on a crusade to change a lot of the legacy
main-frame'ish applications over to web-based applications. Also they are
looking at web-based applications for their new application needs. I would
suspect that there are other such enterprises doing the same sort of thing.
Being an IBM shop they have staked their future on J2EE rather than .NET.
Currently the really big web based apps are coded using Smalltalk or Java
and/or are servlet based typically with Weblogic or Websphere. However the
mid range apps are seeing a healthy growth in the use of ColdFusion (let's
say cfml based apps) which is great news. One of the main reasons they
chose to go with ColdFusion at that level is Fusebox. They are very focused
on building web applications that carry with them a well-distributed
framework or standard/quasi standard, again I would guess this is pretty
typical at the larger enterprises. The important point here is our belief
from direct experience that Fusebox is important in keeping cfml growing in
influence and usage in larger enterprises.
Our belief is the combination of Fusebox, ColdFusion (cfml) and Flash will
blaze a path to releasing web applications from the constricts and
convolutions of pure html where the ever increasing GUI needs get more and
more demanding. We also think that it is great to have competing versions
of cfml providing we don't end up in a situation where something where an
app created for ColdFusion will not run on BD and vice-versa. This would
very much go against the needs of large enterprises in having broad-based
standards/frameworks and would do more harm than good to the future of cfml.
By the way Charlie, all the very best in your new'ish role like Jim Davis
here, you have given so much to the cfml world and very much deserve to be a
continuing leading light because we will all benefit from that.
Kind Regards - Mike Brunt
Webapper Services LLC
Web Site http://www.webapper.com
Blog http://www.webapper.net
Webapper <Web Application Specialists>
-----Original Message-----
From: Jim Davis [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 14, 2003 1:20 PM
To: CF-Talk
Subject: RE: CF Compatability
[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
Signup for the Fusion Authority news alert and keep up with the latest news in
ColdFusion and related topics.
http://www.fusionauthority.com/signup.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
