Hello,

Apologies in advance for the long and OT post. Don't worry, this isn't
yet another cf wish list (or is it?). This really is long and rambling,
so you will need coffee, and you might not want to read this at your
desk... maybe print it and take it home for the weekend?

Unless you've been living under a rock for the past few weeks, you've
probably seen / read / commented on one of the umpteen "CF 8 wish list"
blog postings / email threads / surveys / etc that have been floating
around. Recently, we all got the chance to do the same thing for the
"ultimate CF IDE" on Damon Cooper's blog [1] - which currently has over
100 comments. Reading through those comments, i came away with the
impression that, warts and all, Eclipse based tools are taking over the
cf developer workbench. As we should all know, Adobe is part of the
Eclipse foundation (whatever that means) and even just started selling
an Eclipse based solution for flex...

One of those blog comments, from Mr. Cooper himself, reads:

>I sincerely hope we can both pleasantly shock and awe you with what we
>have on store.
>
>I will say this: the solution we come up with may not be what you're
>expecting, but it may be what just what you've wished for :)
>
>Damon

(For those who don't know, Damon works for Adobe)

For no other reason than the fact that it's Friday and that i've had
waaay too much coffee today, this has put me in full on "conspiracy
theory" mode, so i thought i'd pour out my "what if" before the black
helicopters show up ;)

In short: what if the next version of CF was split into two (or more)
parts: a (probably eclipse based?) client side tool and an (optional?)
server side tool? 

Basically, what if they pulled a Flex on CF? 

Remember Flex 1, the twelve thousand dollar server side component? Now
we've got Flex 2 which comprises:

        - a free of charge SDK / compiler for MXML and AS3
        - a commercial IDE / gui builder, also available with an
optional commercial plugin for charting and graphing
        - a set of server side components which you can buy if you need
them (Interestingly enough, these seem to be free for one cpu servers?)

This is a BIG change in strategy, since it opens the Flex door to people
who don't work in "enterprise" IT. You can now play for free, or spend a
reasonable amount of money for a tool that will undoubtedly make you
much more productive, or go "whole hog" for a set of server components
that will allow you to do more "heavy lifting" kinds of things. Also,
since the SDK compiles your flex apps to a standard swf file, i'm
guessing you can now write a simple Flex RIA (although i guess a flex
"component" would be a better term) and deliver it to a customer **who
does not own any kind of Flex server license** to deploy on their own
systems.

But enough about Flex. Let's just imagine for a second...

1) How would/could this work?

When you think of it, there are already two main "parts" to cfmx. On the
one hand, you have code that parses CFML, generates java code from that,
and hands that java code off to the underlying app server (JRUN or
whatever) to compile into executable code. This is why you can already
pre-compile your cf code today, using the cfcompile script that ships
with CF. If you look into that, you'll see that the work is done by a
call to coldfusion.tools.Compiler, which lives in your
/WEB-INF/cfusion/lib/cfusion.jar. On the other hand, you have a bunch of
runtime services, which is basically all the stuff you find in the cf
server administrator: data source management, scheduled tasks, event
gateways, yadda yadda etc.

This is the question: what if you turned cf into TWO products: an SDK /
IDE combo that included at least the cfml parser and maybe even the
compiler, and a server component that gave you access to more
"enterprisey" options?

Well, if you had a parser and compiler in the IDE, you could certainly
do some pretty amazing things in terms of highlighting errors,
auto-completion, etc etc. A big part of the JDT goodness is made
possible by the fact that your code is constantly being compiled, and
problems and messages are being fed back to you through the IDE. I know
that CFML is a dynamic and loosely typed language, but so is javascript
and you should see what the JSEclipse IDE can do with that. I know that
cf is very runtime bound (by which i mean that you need the execution
context to figure out a lot of stuff), but there's no reason that the
IDE couldn't embed a servlet container like the sysdeo tomcat plugin
does. CF already contains some code licensed under a business-friendly
Apache license, like Axis, bcel, log4j, xalan, etc etc, so something
like Tomcat would make a good match. And once you have THAT, then say
hello to interactive debugging at the touch of a button. No more hassles
with setting up remote debugging, attaching to a different jvm, etc etc.
Obviously this is not going to magically work "out of the box" for hairy
enterprise projects with all kinds of dependencies on remote servers,
etc etc - but in terms of the 80 / 20 rule, in terms of "making
difficult things easier", by embedding a parser and compiler (and
perhaps even a minimal runtime system) into the IDE, you could come up
with some pretty cool features in terms of enhancing developer
productivity.

But enough about that, let's move on. Using a setup like this, it might
be possible to compile an (admittedly basic) CFML application into a war
file that could be deployed on any J2EE compatible app server, without
needing any other software installed. Think about that for a second: if
you work in an agency setting, then you've just done away with one of
the major client gripes about using cf - the fact that they have to pay
for a license (assuming that you don't host it for them). PHP is free?
Well, cf could be kinda free as well... On the other hand, if you work
in corporate IT, you've also made deployment quite easy - just send a
war file to ops and they deploy it like any other j2ee app. No need to
even tell them it's cf and not jsp.

Now, i'm not a business strategy specialist of any kind, i don't know
that the concept of a "cf standalone" makes any sense. That's why this
is one big "what if?"

2) Is this even possible?

No idea. My gut feeling is that it's technically possible, but
difficult, and that there are probably all kinds of issues surrounding
third party code that Adobe has licensed to include in CF (some more
about that later).

I do know that the j2ee spec differentiates between an enterprise
application and a web application, and that one enterprise application
can contain zero, one, or more web applications, so the concept of a "cf
server component" with several nested "cf web applications" is not that
far fetched.

As usual, two things come to mind (i've got a two track mind)... first,
Flex was (is) a much much younger product, so switching it over from a
server based product to an SDK / IDE base would have been much easier.
CF, even in its java form, has been around for a few years and there
might be a lot more "legacy" stuff to change - quite a tight fit if
you're looking at a 2007 release. Speaking of legacy, this would
probably break the cardinal "backwards compatibility" rule - which by
itself makes it **highly unlikely** that Adobe would do it. Secondly,
Flex ultimately produces an swf - a compiled binary file that is
distributed to the end user. CF is for making web apps, and web apps are
client - server by nature... no way around it. That isn't going to
change, but this is about the concept of cf as a "server in a server"
(since cf is actually an app that executes in a j2ee server).

Still, and basically, Adobe is a company that deeply groks tools. These
are the people who made millions and millions of dollars selling
Photoshop and Illustrator. Adobe is a company that deeply groks
ubiquity. They've made more millions and millions off PDF, and the basic
reader is free! And the server market is a tough place to be, and it
doesn't look like it's going to get much easier any time soon... But
with a system like this, you can sell to everyone from the freelance
developer to the IT manager. There's a cf product for all of us ;)

And then you have the magic marketing bs word: synergy.

If we go back to Flex, my understanding is that you need the server
components if you want to interface with any kind of business logic that
lives on your server, say EJBs or maybe POJO/Hibernate stuff. If i
understand correctly, you don't need them to consume web services - but
the promise of how web services will allow you to "easily" tie together
apps running on different software platforms should get a wry smile from
anyone who's ever spent time going through wsdl hell for really knotty
problems. You also don't need them to talk to... ColdFusion. Aaaaaah -
now we're talking. If this "CF IDE" ;) and Flex builder are both
eclipse-based tools, you open up the door on the kind of productivity
that would make Ruby on Rails look slow... and you're developing the
"newest freshest" RIAs, not just some old school web application.
Basically, the only other company that could compete with something like
this is Microsoft, and you've got the advantage that either of the two
components (Flex and CF) is perfectly viable on it's own... but together
they could blow you away. 

3) Yeah, but what about...?

Let's cut to the chase (regarding the concept of a lightweight "cf
standalone"): email handling and data sources. 

I can imagine a cf app that doesn't use event gateways or scheduled
tasks, but everyone needs to talk to a database or send an email
message, so would this mean that everybody needs to buy the server
component to do so? Maybe. Maybe not. Let's start with cfmail. There's
already a difference in cfmail processing between the current
professional and enterprise versions of CF - basically, enterprise can
send more messages per hour. This isn't (i'm just guessing) a difference
in the cfmail tag itself - it's a difference in the code that processes
the spooled mail on the disk. Solution: cf standalone can send mail, but
it can't spool: when it processes the tag, it connects to the SMTP
server and sends the message. And you wait until that's done. OK if
you're sending one or two mails for a mom and pop operation, not OK if
you want to spam^H^H^H^H notify all your customers about a new deal
available on your site. That's when you buy the server components. Now
data sources. This is where it gets a bit tricky, because Adobe does not
make the JDBC drivers that ship with cf, and some(most?) of them aren't
open source. At least some of these drivers are licensed from Merant, so
it will be a cold day in hell before you can distribute them willy-nilly
to your customers without Merant getting paid. The way i see it, there
are a number of possible solutions... here are two:
* cf standalone ships with license compatible open source drivers only.
You can talk to mysql. You can talk to postgresql. Sorry, no oracle. If
you want to talk to a "pro" db you buy the server components. Think
about it this way: the current enterprise version of cf contains
"better" oracle drivers (and maybe some other db's?) than the pro
version. This continues that trend.
* But this is supposed to be a conspiracy theory, so how about this? If
you were to make a listing of every cf based db backed app ever produced
in the last eleven years and group by database, there is one name that
would probably blow every other db away, and that is MS Access. Despite
the fact that "serious" cf developers like to shudder at the very
mention of its name (oh, and it only runs on windows), it has at least
one compelling argument that makes it a good match for "low end" cf
development, which is that you don't need to install a db server to work
with it (yes, i know, the JET engine) - as far as you can tell, it's
"just" an mdb file. Relax, i'm not about to suggest that cf standalone
should only work with access. What if cf included a java based db engine
that you could include as part of your app? Basically, what if you could
ship the database INSIDE your cf standalone application? Obviously this
has a lot of limitations (like two cf apps in separate war files can't
share a db), but it would be very very easy to deploy and, if you need
more, you pay more (and get the server components). Have i mentioned
that such a product exists? It's called Derby, it's under an Apache
license (it was donated to the Apache foundation by IBM).



Right, enough for now. I warned you that this was long and rambling at
the beginning. And i'm under no illusions that any of this has any kind
of likelihood.

I just wanted to ask "What if...?"

Have a good weekend, all.

/t

----------
(watch the wrap)
[1]
http://www.dcooper.org/blog/client/index.cfm?mode=entry&entry=CA4B686A-4
E22-1671-58F4E17F09832C78




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting,
up-to-date ColdFusion information by your peers, delivered to your door four 
times a year.
http://www.fusionauthority.com/quarterly

Archive: 
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:248841
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4

Reply via email to