After getting blasted by the NewAtlanta folks in private (which I don't deny I deserved), I thought I should add some more context for my previous posts about BlueDragon.
First, I'm using BD 6.2 Beta, so bugs are to be expected, and in that sense, I don't really have any grounds for complaining when things don't work. In theory they will, but beta is beta, and it's not perfect by definition.
Second, I undoubtedly appear pretty quick to blast BD for being a "poor" CFML implementation. That's far from the case. NewAtlanta has done a fantastic job with providing an alternate CFML runtime. I'm attempting to wring every last drop of functionality out of the edge functionality CFML provides, and that means I'm constantly living on the "edge cases", where the differences between CFMX and BD are going to be most apparent. Couple that with a beta product, and there's no real reason not to expect as many problems as I've had.
Third, I'm a CFMX user for my day job, and BD is not CFMX (duh). When I get home from the office, I've been in CFMX-world all day, and assume BD ought to function the same way. That's about 95% valid, I'd say, and the last 5% are things that aren't really part of CFML, and are therefore subject to vendor-specific differences. Then there is also the lag that BD necessarily has over the CFMX. Since there isn't a spec to implement, NewAtlanta can only start working on features when Macromedia releases a version of CFMX. So it's to be expected that features which are stable, but relatively new, in CFMX will probably be buggy in BD.
Bottom line, I'm still using BD for my personal development. If the product was really so pathetic, I wouldn't be using it. Yes, it's frustrating a times, and that frustration is reflected in my posts, but in the grand scheme of things, BD's a pretty solid product.
And yes, I am making a attempt to purchase a CFMX license, but that's not necessarily a poor reflection on BD, but rather that using both interchangably isn't something I'm good at. I'd love to not buy CFMX, and instead spend the cash on a Studio MX 2004 upgrade and some random gift for my wife and/or daughter. As things stand right now, I'm probably going to do the latter. The web services bug looks like it should be resolvable without an inordinate amount of effort, and CFMX will return to "not even remotely worth the cost" status.
Anyway, my ranting and raving isn't as bad as it sounds. The day I stop posting about BD is the day that I gave up, so as long as I'm writing about it, rest assured that I see value in using it over other CFML runtimes.
Heh, sounds like you're having a love/hate relationship with the product. Reminds me of being married! hehe
It seems to me that if you're having genuine problems with a product, it's fair to blog about those problems. I don't think New Atlanta should have blasted you privately about your blog posts – you don't "deserve" that at all.
Yes and no. It's definitely up to me to post whatever the heck I want on my blog, but at the same time, slandering BD for bugs in a beta product without giving them advance warning, let alone a chance to help resolve issues, isn't really fair to them. I've developed a relationship with New Atlanta over the past couple months that has been fruitful to both parties (though probably moreso to them), and the value of that relationship weighs into the balance as well.
As for whether I deserve being yelled at for complaining about their product, I'm not going to say it was warranted, but I'm not going to say it wasn't either. That's a decision that can only rest in NA's PR/Customer Support department, and how they want to relate to outspoken users (good or bad) of their product. My comments justified a return outburst, but IMHO, the return outburst should never have come from a business trying to win over a convert (which I still consider myself).
All that being said, I'm not going to complain any less about stuff that's broken. ;)
I didn't think anything you said was out of line. If anything I think you've been pretty patient overall. After the 3rd time having BD not do what I needed it to do I would've chucked it completely! But I tend to be an impatient guy :) I'd rather just shell out the $$ for CFMX Standard and be confident that it works the way it should than waste time troubleshooting. CFMX does everything I need so for my company that decision is easy. I realize that BD has some definite benefits though and the thought of BD for .NET is kind of cool.
Since we seem to be going public with this, and I'm the one who "blasted" Barney (though "blasted" isn't the term I'd use), I'll weigh in with my two cents.
My complaint to Barney was over yesterday's "The Dragon is at it Again" entry, and not any of his previous entries. My issue with yesterday's entry is that he blasted BlueDragon for an error that was apparent to me wasn't BlueDragon's fault at all (based on information he sent me privately that wasn't in the blog).
Well, sure enough, it turned out not to be a BlueDragon problem (see today's "User Error!!!" entry–thanks, Barney, for posting this update). In fact, the problem was caused by CFMX for not uninstalling cleanly.
I expect Barney to be honest and post any and all problems he has with BlueDragon. But I'd also like to ask for the benefit of the doubt, when doubt exists, before automatically blaming BlueDragon for whatever issue he's having.
Robert: The main feature of BD that I like is that it's free. I'd rather have CFMX, but since this is a personal box that I make zero money with, that $1200 is a pretty steep price. Consequently, BD is worth some hassles, because it'll save me that cash.
Vince: The benefit of the doubt is primarily based on prior experience. Prior experience has shown that BD is usually the culprit, so why shouldn't I assume that it's the cuplrit in future error situations, especially when regarding functionality that is tightly bound to other functionality known to be buggy?
I don't want to get into an argument about it, but getting the benefit of the doubt requires earning the benefit of the doubt.