>Been there and done that. I wrote a C++ CGI exe and then an ISAPI dll that passed Text semaphores (containing CGI info) to a VFP exe that was waiting for it with a timer. (BTW, this is the basis for some other 3rd party products out there like FoxWeb and WWC.) It all worked pretty good, but, when VFP MTDLLs became available to work with ASP, I dropped all that in favor of more speed and scalability with the latest technologies. Check out http://www.activevfp.com for more info ...

You know I'm getting a little tired of the misinformation you're spreading around in many places. First of ISAPI and CGI are two totally different things with totally different performance parameters so to lump them into the same box is ridiculous. And you seem to forget the fact that ASP is an ISAPI application in the first place as is ASP.Net (at least the base part of it that hands off the manage code handler) and every other tool that Microsoft provides.

Secondly, Web Connection is a COM based environment and doesn't need 'semaphore' files (which BTW is the wrong nomenclature - a semaphor is a locking mechanism and has nothing to do with messaging) and although it can operate with files it does so, so you can debug your app in real time inside of VFP for development purposes.

FInally, ASP and COM objects which is what ACtiveVFP does (right?) is not faster than the same thing performed using a properly optimized ISAPI extension like FoxISAPI or WWWC. While little do nothing hits maybe slightly faster in ASP/COM/COM+ (and all three are required to do be so) just from an aspect of load time, anything more complex that accesses data will be *much* faster in a COM pool environment because of the inherent caching available in those servers whereas ASP COM objects must always reload everything. The overhead of reloading one or more objects plus re-opening all files or re-establishing ODBC connections each time will kill any single load advantages a ASP/COM object may have in load time very quickly.

Web Connection can actually run in ASP mode to take a WC app and run it under ASP as a COM object so it's real easy to compare performance of *exactly* the same code - I don't want to get into a whole debate what's faster and by how much, but let's just say that ASP is definitely not faster...

So speed and scalability are hardly an issue especially since real scalability is not controlled by the the Web software but the ability to scale out when needed, which works equally well for any solution whether it use CGI, ISAPI or a scripting engine like ASP.

I'm not trying to disuade anyone from using ASP and COM objects which is a very viable choice for Web development. But I won't let invalid information that relates to my own products and related technologies go without a rebuttal...


+++ Rick ---