Terry,
like I said - why even get started with these technologies(foxisapi, CGI Fox query server) - they're difficult to implement and are inferior as far as scalability and performance? I understand going with the underdog(after all we're still with the fox!), but, after you try to implement foxisapi a few times you'll probably understand that it's not worth the effort. WWC is a take off and improvement of both of these so you can think of it as a foxisapi on steroids (WWC COM mode is like foxisapi and WWC file mode is like the old Fox CGI query server only updated to isapi for better performance). If you want the best of scalability and ease of use, go with VFP mtdlls called from ASP.NET or ASP. This is newer technology that use actual multi-threading, not a MT simulation where there are several vfp .exes in the background. ASP and, eventually, ASP.NET, are built into the OS and are optimized and safe - you just add your vfp web app by creating a vfp mtdll...
>I agree with you!
>
>We were discussing the issue of time vs. $$$.
>My hope is that the COM I am working to manage the business logic, and prototype under foxCGI will easily translate to an 'active' service. This is one of those cases where the business rules are about 3000 pages of PDF's (I always seem to get the gigs where the specs are deivered in piles of calculus and a wink with parting words like "good luck"). Solving the business logic is 99.9% of the work. Prototyping the [business] COM with CGI is a phase - a migration to active services will come later.
>
>Solving the front end issue first may be akin to doing a form layout (a lot of people do this) before understanding what the data looks like and what the business rules are. First glance - it looks productive - it is tangible (we can see the the GUI) - but it is meaningless! It does nothing except occupy a plane of pixels!
>
>Admittedly - solving the the problem from the inside - then - working out is old fashion - but with complicated business logic what alternatives are there? I would like to avoid the business logic - and have fun - and look productive by thrashing the ASP - but in this case - the 500lb gorilla is the business module and not server services.
>
>FoxISAPI has problems that have never been fixed.
>Imagine how many licenses of a wwfoxISAPI could be sold once you make it better and put your logo on it!!!:) I read a DevCon report about your DevCon presentation in 1998 as "foxISAPI without foxISAPI". I'd buy one (or two)!
>
>There are a lot of people still doing it. You get on foxcite or other boards and people are going crazy with it. The foxISAPI packaged with VFP is not the only flavor of foxISAPI out there. There are a few people hacking it - trying to make it better.
>
>Almost every tool from Microsoft or third party companies is considerably easier to use than FoxISAPI.
>All I need for my testing are the FormsVars from a POST or GET. I am working with "Shared Content Object" models - weird stuff - lots-o-DOM - very little database.
>
> Like a few days ago I had a simple question about a CGI script I needed for what I was doing. I wanted to ask - but when those kinds of questions are asked (on the UT) - regardless of the reasons for the "need to know" - the response [typically] is: Why don't you use ASP?
>
>The answer could have come from this board in a few minutes. But rather than being pummeled with usual rational - and upsetting everyone - I googled and burned a few hours extra just so I would not "burden" anyone!:)
>
>It was interesting technology at the time because there was nothing else from Microsoft anyway.
>I set up a couple of "adult entertainment" sites using a 16bit "WebTools" product from Delta-Point (circa 96-97). Those little CGIs managed 10s of thousand hits a day!
>
>I am sure there are more intersting technologies to come - and I am sure west-wind will be continue to lead in those technologies. I just need to figure out better ways to mask (... err ask) my questions:)
>
>Terry