In my opinion, there should be no middle ground for installer packaging. I think that statement is merely a cop-out. I do not agree that people "do not want" a comprehensive installer package.
I am a firm believer that the installer package should address every configuration that the software author claims to support in their sales documentation. Anything less, and I believe you are short-changing the purchaser, as well as risking loss of sales of the product, due to complexity of the install and configuration process. This issue is major enough in scope, that I am also of the opinion that it is a reason so many enterprises have decided to delay or just not upgrade. Hello? MM, are you listening? It makes no difference to me if there are fifty people installing the software in one pass, and one or two (I suspect it is much higher) have broken installations due to omissions in the installer scripting and/or the documentation. You guys can BLOG all you want, but until a solution is reached, you are still delivering a crippled software package, and that no doubt is affecting sales, or lack of sales. Secondly, if any of the components require configuration, then that should either be addressed as options in the original installer package, or at least in the CF Administrator applet. I actually consider it a dumb design scenario to have multiple configuration applets, all of which must be hacked, tweaked, or whatever you call it before getting down to work with the product. I don't think you need to address EVERY configuration scenario, but you MUST address all of the ones your own sales hype claims to support. Period, end of story. Perhaps someone needs to recognize that the installer package is the first "face" that you present to your customer. There should be a gigantic effort to make sure this is a pleasant experience, not just some of the time, but ALL of the time. The best engineered software in the world is doomed to failure if it will not smoothly install and configure in a simple and efficient manner. Someone should realize that in a production environment, developer types are not the ones doing the installation and configuration of server products. In many shops, the developers do not even have the access permissions or are many miles away from the scene. What good is it to concentrate all engineering resources to the core product if the customer cannot successfully install it and as a result refuses or delays buying it? I too, am participating in the Red Sky project, and that is where I got the impression that MM was addressing some of the installer issues. I have made a lot of input, but must await disclosure by the MM folks before I can discuss them in depth. ====================================== Stop spam on your domain, use our gateway! For hosting solutions http://www.clickdoug.com ISP rated: http://www.forta.com/cf/isp/isp.cfm?isp_id=772 ====================================== If you are not satisfied with my service, my job isn't done! ----- Original Message ----- From: "Sean A Corfield" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Saturday, June 14, 2003 10:05 PM Subject: Re: Installing MX for JRun with no context root | On Saturday, Jun 14, 2003, at 19:24 US/Pacific, Doug White wrote: | > The is the repeated argument on the installations. Why must anyone | > drill down | > to anywhere? Why cannot the install package provide the options and | > then do the | > job? | | Each J2EE app server provides a different way to manage the | applications it runs and JRun itself has an extremely good | administrative UI. If the install package had to allow users to | customize all of these myriad options it would (a) have to be a much | more complicated installer (which people don't want) and (b) it would | require a different installer for each app server (which might divert | resources away from other, more important core features, as well as | making it impossible to offer a pure Java version that installs on any | J2EE server). | | The installer takes a middle course, providing many of the basic | install options that most people need but leaving the more esoteric | options to the individual. I've installed CFMX Server and J2EE edition | on three different platforms (Mac, Solaris, Windows) in a variety of | configurations and there are only a few 'tweaks' that I've needed to | perform via the underlying J2EE application server - with the exception | of the very specific shared document root setup used on a couple of our | servers (documented on my blog - I was the first person to attempt to | install it that way and the product team worked closely with me to make | it work - and most of those contortions are no longer relevant since | CFMX Updater 3 makes it easy to share a document root... I'll update | the blog entry at some point!). | | Sean A Corfield -- http://www.corfield.org/blog/ | | "If you're not annoying somebody, you're not really alive." | -- Margaret Atwood | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
