>>
>>Hmmm.... OK, I think I understand what you are saying, but now I have 2 more questions:
>>
>>1. With COM the component runs on the Web Server, with DCOM it runs on a different machine other than the Web Server. What would be a good example of WHY you'd want to use DCOM?
>
>You might run the DLL inside Microsoft Transaction Server (MTS) that is running on another machine. You'd do this for scalability and performance.
>
>>2. You say I have to think 'connectionless', with this in mind, is there going to be a problem if one of the jobs my COM object is trying to do is to write data to a VFP table that is sitting on the user's machine? If it's 'connectionless' will it be able to see and write to the table on the user's machine?
>
>No. I can only write back to the place that created it, ie: and active server page. The client application knows nothing about the COM object. However, you can make it work the way you want, but the client will need to run Internet Explorer. I don't think this will will work in Netscape.
>
>1. With your application, you will distribute COM component A (COM-A).
>2. The user will go to your web site in their browser and enter the code.
>3. The ASP script on the web server will launch COM component B (COM-B)
>4. COM-B will determine the key that is needed and return this information to the ASP page in the form of an ADO record set.
>5. The ASP page will generate a return HTML page and send the HTML page and the ADO record set to the client.
>6. The HTML page will instantiate COM-A on the client.
>7. COM-A processes the ADO record set and updates the VFP table.
>
>Simple, huh!
>
>>
>>Thanks!
>> ~ellen

Hi Ellen, Craig-

PMFJI (again) but this all seems like total overkill to me. Ellen, if what you want is a programmatic interface to a logic on a web server, you don't need to use ASP at all- you don't even need to use HTML. All you need is the tools for the client to initiate a process on the server, and get a response from it, all communicating over the WWW using HTTP. If you don't need a web page, don't use one.

If I had to tackle this problem, I would simply create a COM object to run on the server, and call it with FoxISAPI. I would then use Rick's wwIPStuff class on the client side to build a Request and send it through the windows internet interface- directly to the server (no browser).

This could all be really simple.
For the server class:
DEFINE CLASS GetAuthKey AS Custom OLEPUBLIC
PROCEDURE ProduceKey
LPARAMETER lcFormVars, lcIniFile, lnReleaseFlag
LOCAL lcOutput
lcOutput="HTTP/1.0 200 OK"+CR+; "Content-type: text/html"+ CHR(13)

* Calculate the key and record that a key was given
* IF you need to, you can pass this method parameters in the
* URL, and they are received in lcFormVars- you just have to parse
* them out.

RETURN lcKey

Then, on the client, use wwIPStuff
SET CLASSLIB TO /classes/wwIPStuff.vcx ADDITIVE
oIP = CREATEOBJECT('wwIPStuff')
lcKey = oIP.HTTPGet('www.MyServer.Com/FoxDirectory/FoxISAPI.dll/MyProject.GetAuthKey.ProduceKey')

?lcKey && Now holds the value you returned in Produce key.


That's it!!!!

THere are a few issues youhave to get out of the way as far as configuring your COM server and getting FoxISAPI set up, but that stuff is textbook if you know where to do your homework. And your homework is at http://www.west-wind.com/presentations/foxisapi/foxisapi.htm.