Christof,
You had mentioned before that you didn't use(or emphasize) mtdlls in AFP because of some problems a client had encountered. If it's still supported in AFP I think that's a step forward, but, I got the impression that there wasn't much enthusiasm for it in your product anymore. WWC was similar - he stuck an asp/mtdll feature in there, didn't really support it, and told anyone that tried it not to use it!
As far as regular AFP being truly multi-threaded, is it? I thought it had several vfp exe process servers running in the background? Please correct me if I'm wrong. If this is still the case, then it is not truly multi-threaded, unless I'm missing something...

>Hi Claude,
>
>> 1.)ActiveVFP is the only truly multi-threaded of this group because it uses VFP mtdlls (as do vfp web services).
>
>Wrong. AFP uses multi-threaded MTDLLs, too. Unlike AVFP, AFP runs on a variety of web servers including IIS, Appache, WebWeaver,...
>
>> This means a lot in terms of speed, scalability, and efficiency.
>
>Do you have any figures to show this? Our auditing of web applications showed that the biggest factor was always data access. And frankly, most VFP applications on the web have something to do with data access.
>
>>> For example, with ActiveVFP, all vfp web threads will share the smaller vfp runtime.
>
>As do all the threads in AFP. Except that in AFP, the web server talks directly to the web application whereas in VAFP you have the additional overhead of ASP.
>
>> In contrast, the other tools simulate multi-threading by starting 2-3 vfp processes(typically).
>
>That's just plain wrong. I've been telling you this in the past, and I repeat it here. AFP doesn't simulate multi-threading, it implements true multi-threading. Unlike AVFP, in AFP you even can control the entire environment because the threading engine is available to you. You can even create your own true multi-threaded background threads that perform lengthy operations without having to build an MTDLL in VFP.
>
>> A VFP process (or channel as it's called in Foxweb) will load a copy of the larger VFP runtime with each instance.
>
>Yes, it's 1.2 MB compared to 3.5 MB. However, the .NET runtime and ASP.NET engine also consumes memory (the framework is over 20 MB huge). AVFP needs to load the .NET libraries in addition to the VFP libraries. All other tools just require the efficient VFP runtime, AFP even only the MTDLL one.
>
>> Processes have much more overhead than a thread.
>
>Exactly. This is the problem with AVFP. It relies on the .NET infrastructure that cannot operate in the IIS process space. Instead ASP.NET launches a new process (called the worker process) for every app pool and communicates with the web server through named pipes. Guess what AFP does? It communicates with the web server through named pipes. The only differences is that AFP can do so directly, whereas AVFP can only communicate with ASP.NET through slow COM InterOp means. ASP.NET then has to use a named pipe to send the result to the web server. Instead of copying the result once, AVFP needs to copy it at least twice.
>
>> It doesn't take a rocket scientist to figure out that if you have more than 3 simultaneous requests with 3 server processes, somebody will end up waiting.
>
>The other two maybe? On a single CPU computer, only one thread or process is ever executed. You also forgot to mention that AFP has a dynamic load adjustment and instantiates new MTDLL threads as needed to cope with increased load as well as releases them if load decreases.
>
>> >2.)ActiveVFp is the only completely free and Open Source choice among this group for vfp web apps.
>
>Free is relative. You still need at least a Windows server license because AVFP requires IIS. You need to deal with CALs, because IIS requires them in order to authenticate users. You still have to buy VFP, because otherwise you cannot create MTDLL. WebConnection and AFP, on the other hand, can use Apache and don't require you deal with CALs and the like. If you look at the total costs of each solution, they don't differ that much. Especially considering AFP Express (which costs only 99 Euro), or WebConnections runtime licenses which reduce the costs to $31.98 per server if you take the 50-server license, for instance.
>
>>3.)ActiveVFP is the only one to integrate with ASP.NET.
>
>You mean, ActiveVFP is the only one that requires the overhead of ASP.NET. <s> Why would I want to write an application partly in ASP.NET and partly in AVFP? Calling COM components from an ASP.NET page is fine, but then I'd use business objects, not AVFP applications.
>
>>AFP and Foxweb concentrate on placing vfp code within the HTML like Classic ASP does.
>
>Again, again, again... That's completely wrong. AFP puts code into a code-behind file just like ASP.NET does and fully supports PRG and VCX based classes (We've takled about this in the past). Unlike VAFP, in AFP you can truly reuse your business logic and build it into the web application without going through all the hassle to convert them to COM objects, without all the problems you have with debugging.
>
>Debugging in AFP is as easy as starting VFP, launching a utility called AFP3DEBUG and then just stepping through the code like you do in a regular application. You can debug AFP applications in their native environment using real, live requests. You don't need any simulation or work arounds as you do in VAFP.
>
>> ActiveVFP and wwc offer this way and the option to keep the application code in the dll or exe and process HTML templates. This is the more modern way and the way ASP.NET works (code-behind).
>
>AFP gives you the choice how you want to write your code without any impact on performance. AFP 3.0 was modelled after ASP.NET 2.0 and therefore has one of the most modern designs. Not that this is really important, but you seem to like the old vs. modern design comparism. <s> Unlike VAFP, BTW, that uses MTDLLs in the same manner we used to program back when they were introduced in the late 90ties.
>
>>Many developers have described wwc as hard to learn. There was even a book that described it as being a "bitch to learn". I've used wwc quite a lot and I would have to agree. That's one of the reasons why I created ActiveVFP...
>
>Many developers describe VFP as hard to learn, because it's not procedural (when you are dBase developer), or because the object model is completely unconventional (when you are a C# or Java developer), or because data access is way too difficult (when you are an Access developer). WWC requires you to learn an object model and implement applications at least partly in classes. That's true. But then, if you have a three-tier application you already deal with a complex object model.
>
>Learning the object model, learning the product is not the hard part of web development. With AFP, it takes just a few minutes to get the first paqge running. As does it take in ASP. However, the hard part is to get you mind around the concepts of web development, around stateless applications, around session handling, around the loss of application flow (a very important topic), around security issues (an even more important issue), and so on.