It's still ISAPI on the client side. You can think of it as a COM server on the server side and it's basically 1 ISAPI extention dll(be it ASP.NET,ASP, foxisapi(-although I've never seen foxisapi talking to a mtdll,it says it's possible in the source code docs) talking to a VFP mtdll.
>This is good news indeed! The Hsia paper was a boost to the project! It was the first paper that I've seen that detailed the mechanics of pooling and thread management with VFP MTDLLs. It was positive on VFPMTDLL's as a service, detailed thread management and error control issues. We don't get that kind of info from most of our "sources".
>
>I am beginning to understand it is not CGI. But I am at a loss for a term that describes this architecture.
>
>Again, Thanks!
>
>>Everything will seem fast with 1 web hit, even "file-based" communication. That part can be deceptive. The real test is when you receive many web hits. Yes, the vfp runtime loads up with each vfp server you have running with foxisapi. You should see 3 or 4 VFP exes running in Task Manager under Processes. Foxisapi loads up 3-4 servers by default that wait in the background for web hits.(what happens when you have more than 3-4 hits at one time - they wait!) VFP mtdlls, on the other hand, only load 1 instance of the vfp runtime that is shared among the threads(true multi-threading). All of this processing happens on the server, btw, and there is caching on both client and server. (also none of this is CGI)
>>>My prototype "internet" project is using foxISAPI and VFP coms (thank you Mr. Strahl!). Later parts of it might move under (or beside) a "commercial" com.
>>>
>>>My last intense "html" project was in the 90's. I don't think the technology (or at least my knowledge of it) allowed for client data stores. Now (it seems new to me!) we can "manage" the stores at the client (setting and reading value attributes).
>>>
>>>It also means the server does not have to be burdened with all the caching responsibilities!
>>>
>>>One suspicion (myth?) I held regarding an IIS/foxISAPI.DLL/VFP COM/Browser architecture was that every time the com was instanced, a vfp runtime would load into memory. That one busted. It didn't happen!
>>>
>>>I also thought it would be slow - but its surprisingly fast - even opening opening and closing DBFs was quick as "whatever" - and still - VFP runtime did not show as a process.
>>>
>>>I did "load" VFP once - and cannot be sure a localhost can see a "loaded" vfp runtime. But the cgi response seemed somewhat "quicker" - but it could have been wishful thinking. Any feedback on this appreciated.
>>>
>>>I was also amazed by the fact that moving the mouse across the IE client ate more CPU than a VFP com method transacting with a DBF.
>>>
>>>NO VFP runtimes ever loaded. Who is parenting the my little VFP COM when the url makes a cgi request? I thought runtime needed to be "loaded" to do that.
>>>
>>>Thanks