I guess I will go first then.

The answer is: "It depends".

Like Adam pointed out both of them are mature and very capable engines. Both
have their stronger/weaker points, it is just matters what you are looking
for. My over all impression is that those more comfortable in a J2EE
environment may favor OBD where Railo is more inline with those more
comfortable with "traditional" CF environment.

I have evaluated them both on Windows 2003 and Centos Linux as stand alone
servers, running as WAR's on top of Tomcat, and in conjunction with Apache
and IIS,  with my intention of using them as a primary CF engine for
projects. And based entirely on my personal preferences I have made the
decision to go with Railo.

I like both. I have worked with the paid version of BD's Server JX  and came
"This close" to buying JX a couple of years ago. I foresee using both of
them in a production environment in the future, but at this juncture I am
partial to Railo.

These are the factors that went into choosing one over the other.
------------------
Railo comes packaged with connectors for Apache and IIS.

OBD connects to Apache using a proxy (mod_proxy_ajp/mod_proxy) and TTBOMK
you need a third party module to connect OBD to IIS. My understanding that
Apache takes a significant performance hit when used as a proxy to a J2EE
server (This effects both Railo and OBD). I don't know if the same is true
for Railo's connectors.

It is arguably more dificult (a steeper learing curve) to get OBD running
side by side with PHP under Apache than it is with Railo. It requires a
non-trivial understanding of Apache's .conf files to run OBD side by side
with PHP.  At least this was my experience when running OBD under Tomcat.
Perhaps others have had a different experience. BTW I have not tried
running  OBD side by side with PHP on IIS.

OBD is Licensed under GPL, while the soon to be open sourced Railo 3.1 will
be Licensed under under the LGPL. This means you have the option to bundle
commercial apps with Railo with out having to open source the commercial
apps under the GPL license, while with OBD any apps that you bundle with it
must be released under the GPL license. IMO LGPL is much more flexibility in
this respect.

Railo has (and the OS version will be released with) a mature, production
ready web GUI wheres OBD does not. OBD is rolling their own Admin and it is
not production ready. It has no login/security and they even state on their
site that "Currently has no security in place, we do NOT advise using the
admin console in its current state on a production or otherwise important
instance of OpenBD."

On the up side for OBD is that you can use the admin of Blue Dragons
developers version to create the XML and copy it to your OBD instance.

You have to restart OBD in order to add a datasource.

Correct me if I am wrong on this but last I knew Railo is part of the CFML
Language Advisory Committee and will be working with Adobe in defining the a
CFML "Standard". It is my understanding that, for what ever reason, OBD is
not a part of the Committee.

Railo is more CF 8 compliant than OBD. Railo is a couple dozen tags and
functions short of Adobe CF 8. OBD is still pretty much V.7. A major factor
in my my decision making process was Railo's inclusion of cfdbinfo.

If I am mistaken or missinformed on any of this please feel free to correct
me.

Thanx
~G~

-- Gets a new bag of popcorn.


On Tue, Oct 7, 2008 at 2:24 PM, Philip Kaplan <[EMAIL PROTECTED]> wrote:

> Railo vs BlueDragon vs Smith vs ??
>
> http://www.smithproject.org/
> http://www.newatlanta.com/bluedragon/
> http://www.railo.ch/
>
>
> 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to 
date
Get the Free Trial
http://ad.doubleclick.net/clk;207172674;29440083;f

Archive: 
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:313583
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