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]
