Vince, Thanks for the reply! Most of my concerns are over things that seem fairly innocuous at first, but wind up being huge problems farther down the road. Some inconsistent behaviors are behaviors that I actually think you guys *corrected* vs CF, but unfortunately, those corrections break assumptions that have been made in CF for many years.
A couple of the quick ones in this category would be the proper handling of CGI.PATH_INFO in BlueDragon, the addition of "." and ".." to CFDIRECTORY, and the way that a query reacts in <CFOUTPUT>#query.column#</CFOUTPUT> when no rows were actually returned. These all seem fairly minor, but have some pretty dramatic consequences at times, and can be devilishly hard to track down! Then, for us, one of the big killers is CFCHART :( We've grown heavily reliant on this dandy of a tag, and would absolutely need it before moving onto the platform. The biggest concern for me overall though would be testing and review - our app is currently around the 250,000 lines of code mark, and that's a QA review I don't even want to consider! I do love the idea of having a second CF platform out there, but I just couldn't really see myself using it unless it was mark for mark compatible with MM:CF, even when MM:CF has minor inconsistencies. Maybe if BlueDragon had an application.ActLikeMM attribute ;) I would be happy to get more in depth with you off list (or on for that matter) if you like. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vince Bonfanti Sent: Tuesday, January 20, 2004 10:39 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] BlueDragon Compatibility (was: Threading question) Hi Roland, First, I agree with you that CFML compatibility is critical for BlueDragon. But, I'm curious about some things: 1. Have you reviewed the BlueDragon 6.1 Compatibility Guide? Most of the issues that existed in BlueDragon 3.0 have been resolved. 2. Are you aware that most of the incompatibilities between BlueDragon and CF5 are the same as the incompatibilities between CFMX and CF5? 3. Which specific compatibility issues are critical to you? We try to be very responsive to our customers (and potential customers). So far we're being told that the remaining incompatibilities in BlueDragon 6.1 are not major issues--I'd like to know your perspective. I'd be very interested to work with you to get your application running on BlueDragon.NET--without any conditional branching code (the first public beta is planned for release in Feb). It could be a good learning exercise for both of us. Let me know. Regards, Vince Bonfanti New Atlanta Communications, LLC http://www.newatlanta.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Roland Collins > Sent: Saturday, January 17, 2004 2:53 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Threading question > > > I absolutely agree that it would be nice to have at true CF > standard . . . maybe it's really ECMA/ISO time? > > I think my real need is compatibility with MM's version of > CF, which is really the "flagship" version, even if it isn't > a true standard. Our application gets resold, and by and > large, our client base (large, conservative financial > institutions with large, conservative IT departments) won't > buy anything that isn't written or developed using some form > of "mainstream" technology. Even after years of success, > it's still difficult to convince a lot of our sales audience > that CF is a viable, not going anywhere, mainstream > technology. A lot of places still perceive it as a toy > despite its stellar track record (though this is finally > starting to change, thank god). If we were to then say that > the product has to be run on something other than the > commonly accepted norm or flagship version of CF because of > API inconsistencies . . . we'd never have a chance of a sale! > > I love what BlueDragon is doing, and think it's great work > (I'd actually like MM to incorporate a lot of the new > functions and a few changed > behaviors ;). There are other issues as well though, such > as we could > never have conditional branching based on the runtime > implementation due to > the sheer size and scope of our app. In then end, I just couldn't > realistically use it unless it maintained full compatibility > with the original CF. > > I appreciate your insight though; you bring up a lot of good > points, especially about standards and competition, that MM > would do well to take notice of. > > So I'm back to my .NET System.EnterpriseServices libraries > and .NET to COM interop! CF does actually work with .NET > components (if anyone was remotely curious), but only if > they're written and registered right. Se la vie! > > Roland Collins > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Matt Liotta > Sent: Saturday, January 17, 2004 11:52 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Threading question > > I wanted to respond to your comment since it is interesting in many > ways. > > First, you refer to BlueDragon as a non-standard CFML implementation. > As there is no CFML standard, I don't really see how this is > a problem > for BlueDragon since it would be equally correct to say that > ColdFusion > is a non-standard CFML implementation. On the other hand, > maybe it is a > problem for BlueDragon and ColdFusion alike. Standards are > good things > and have done wonders for other languages that have gone that route. > After all competition is important and having a CFML standard would > allow competition in the CFML market without developers fearing > incompatibilities. > > Next, it is nice to see that New Atlanta offers a CFML compatibility > guide and that people are reading it before diving in. Again, I see > this as another opportunity for Macromedia with ColdFusion. As > different as ColdFusion 5 and MX are it would be useful to have a > compatibility guide documenting the differences instead of developers > assuming there are none. I know plenty of people who had problems > upgrading. Then again, I know plenty of people who didn't have any > problems. I suspect the situation is very similar with > BlueDragon where > depending on your application the compatibility issues may or may not > be a problem. > > In regard to moving your application over, be aware that once you > indicate a desire to be a customer, New Atlanta can work with you on > addressing your specific issues. Right now I am working with a client > that needs to deploy their CFML application on both J2EE and .NET > servers. As such, I recommended using BlueDragon. The application has > some CFMX specific features in it that we have asked New Atlanta to > address. Since BlueDragon.NET is still in alpha we may > actually be one > of their first customers, which comes with it certain privileges. If > you have a CFML application that you want to interact with .NET in > anyway, it behooves you to at least talk with the New Atlanta > folks and > give them a chance to answer to the specific > incompatibilities you are > concerned about. > > As far as loyalty to MM goes, I hear you. Unfortunately for me, the > companies I have been loyal to over the years have always managed to > let me down sooner or later, which has led to me evaluate products > strictly on a technical basis. > > -Matt > > > On Jan 14, 2004, at 3:38 PM, Roland Collins wrote: > > > We've toyed with the idea of using BlueDragon for this purpose, but > > I'm kind > > of hesitant to use a non-standard CFML implementation, > especially after > > reading through the CFML compatibility guide. At this > point there are > > still > > too many breaking changes for me to consider moving our extremely > > large app > > over given the testing that would ensue. Then there are > always the MM > > loyalty issues ;) > > > > I think it's WebServices integration with .NET for now! > > > > Thanks! > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf > > Of Daniel Daugherty > > Sent: Wednesday, January 14, 2004 10:11 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] Threading question > > > > You might look at Bluedragon. The .Net version if I remember > > correctly has support for .Net objects via createObject. > This is if I > > am remembering this correctly.(not quite awake this morning.) > > > > Daniel D. > > > > -----Original Message----- > > From: Roland Collins [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 13, 2004 8:07 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] Threading question > > > > > > Awesome - that's exactly the type of info I was looking for. > > > > Yeah - we've got a lot of points of integration with legacy > systems in > > our > > application, including a lot of legacy COM objects. We're > trying to > > replace > > as many of them with CFCs as humanly possible, hence my question. > > > > Now if I could only convince them to add support for .NET objects in > > CF . . > > . (BlackKnight doesn't count). > > > > ;) > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf > > Of Matt Liotta > > Sent: Tuesday, January 13, 2004 7:54 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [CFCDev] Threading question > > > > It's not every day you see VB on a CFML mailing list. > Anyway, the best > > way to go is to use the Java thread sleep method. There is a > > difference between blocking the thread using Java vs. COM. > > Specifically, you will block more than one thread with COM. > > > > -Matt > > > > > > On Jan 13, 2004, at 6:42 PM, Roland Collins wrote: > > > >> Hey guys, > >> > >> I'm writing a function that waits for a short time for a file to > >> appear > >> before timing out. The basic idea is > >> > >> function WaitForFile(somefile, timeout) > >> starttime = now() > >> bFileExists = FileExists(somefile) > >> > >> loop while not bFileExists and (now - startime) < timeout > >> Sleep(1000) > >> bFileExists = FileExists(somefile) > >> end loop > >> > >> return bFileExists > >> end function > >> > >> Since CF doesn't have a Sleep function, I'm stuck with > workarounds. > >> I can do it either by accessing the java.lang.Thread classes (much > >> thanks to Christian's Blog at > >> http://www.markme.com/cantrell/archives/002801.cfm), or > >> by writing a COM object that does effectively the same thing. The > >> question > >> is: does blocking the currently executing CF thread using the java > >> Sleep() > >> method differ from blocking it using a synchronous COM method ? In > >> other > >> words, does anyone know of any internal CF quirks that > would make it > >> less > >> safe to use the java method vs the COM method? > Future-proofing is not > >> a > >> concern at this point, though I'd wager support for the java base > >> classes > >> isn't being removed from CF any time soon ;) > >> > >> <CFSCRIPT> > >> thrd = CreateObject("java", "java.lang.Thread"); > >> thrd.Sleep(javaCast("long", 10000)); > >> </CFSCRIPT> > >> > >> TIA, > >> RC Collins > >> > >> > >> ---------------------------------------------------------- > >> You are subscribed to cfcdev. To unsubscribe, send an email to > >> [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the > >> message of the email. > >> > >> CFCDev is run by CFCZone (www.cfczone.org) and supported > >> by Mindtool, Corporation (www.mindtool.com). > >> > >> An archive of the CFCDev list is available at > >> www.mail-archive.com/[EMAIL PROTECTED] > >> > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email to > > [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the > > message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email to > > [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the > > message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email to > > [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the > > message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email to > > [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the > > message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
