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]
