Rick,
This is a good defense of .Exe servers. The problem I see though is that many developers are have gotten the mistaken impression that having .Exe servers or even single threaded dll servers is "safer" for some reason which is not true. vfp mtdlls can easily be stopped and started without affecting IIS or other applications. Also, they just seem to work smoother. You never have to worry about starting them in the background or hacking up SRVANY to have them start automatically when startup occurs. All of this happens automatically with mtdlls. Add to this the horror that is DCOM configuration of .EXE servers and it adds up to a lot of time with manual configuration that may or may not work. Also trying to explain to clients that their web environment has 3 .EXE vfp servers servicing thousands of web users and it just doesn't sound right, deservedly so. I have seen many, many large scale VFP web apps built with this configuration crawling and I see VFP mtdlls as an improvement to this situation. It can only help to have a lot of vfp developers using this technology and developing it more instead of being scared off for the wrong reasons...
BTW, nobody uses your mtdll version of wwc because it is actively UNsupported by you with little documentation. I have seen users ask about it on your support board and been told just not to do it that way. Also, why did MS choose vfp mtdlls and not .EXEs as the basis for vfp web services and make it the standard for VFP web development??
>Interesting 'analysis' and I resent having technology, that has proven itself in a huge number of real world apps, called a 'hack'.
>
>There's nothing wrong with EXE servers in IIS - it's no less of a 'hack' than using COM DLLs which ultimately use exactly the same model. COM and IIS in any combination is not exactly stable technology. These days in light of Microsoft's shift away from COM to .Net you hear this even from Microsoft.
>
>Both use STA model components to access a COM object. That's the whole point of COM remember??? It doesn't matter whether you access a DLL or an EXE. The difference with an EXE is that it's a proxied object always, where a DLL may or may not be proxied (in IIS it mostly is proxied because of thread issues).
>
>The reason I long have used EXEs (in Web Connection) is because you can do something that you can never do with a DLL in ASP: Manage it! With an EXE you can control the lifetime of the server and more importantly you can detect a failure and reload it, which you cannot do with a DLL in IIS. If you ever crash a DLL it will require an application restart to get it to run again.
>
>You can also control load to limit the amount of instances that are active so you don't overload hte system with long slow running requests (like crunching a report).
>
>Yeah for trivial applications none of this may matter much, but for production applications that need to be updated in real time, and need to be remotely administered to do things like maintain FoxPro tables (with SET EXCLUSIVE for example) management is unescapable and impossible to do with DLLs and the ASP/COM model.
>
>FWIW, Web Connection has for years included a DLL base class module that allows a WWWC application to run as an ASP/COM component. Nobody uses it although a number of people have played with it and even after requesting it those folks went back to using hte EXE model. Reason: You have to give up too much to play that way...
>
>So while it may be that ASP/COM is what comes out of the box that doesn't mean that using something different is automatically dated or no longer a valid technology. I think the number of people using (and having paid for) and continuing to use this 'hack' technology more than bears out that premise.
>
>
>+++ Rick ---
>
>
>>ActiveVFP is using the ASP and ASP.NET isapi dlls and inheriting objects from them, so, it's still ISAPI and still just as fast if not faster than FOXISAPI. The key difference is the backend vfp servers - whether an .EXE COM server or the more modern multi-threaded VFP .DLL COM Server. FOXISAPI and some of the other 3rd parties are using multiple running .EXE COM servers, which always has been sort of a hack, while VFP Web Services and ActiveVFP use Multi-threaded VFP dlls which is the best environment for using VFP on the web...
>>
>>>I think so I couldn't understood somethings. Than your Activevfp don't use foxisapi?