>OK I get it .. but not really. I was thrown off by your showing of the XML handling in a regular ASP page.
>
>I have no idea how you would do that. I wonder what is the advantage of using something like foxISAPI. Why are you using it? (just curious))

One advantage may be that it does the job. The patron has an enterprise system using foxpro COMs and SQL that feed about 80K hits on 30 or 40 servers/day.

It's being used because thats what the patron specified. The "patrons" are skilled VFP/DBA/Web Services developers and entrepreneurs. It works pretty good - just little bits of data. Content requests are forced by returning little html strings with a "load" event that fires (and targets) the "user" content (activities). The API (a real honest to gosh JavaScript object) provides a generic request reference (EE 1484-11) that third party content can interface through. It's not an everyday project. It's very hairy and painful - but a lot of fun. My patron wants it lean. The server load is minimal - the client load is minimal - infact - the client provides the entire runtime store (without cookies). There is a medium transaction when a session begins, and at session exit. In between the user will navigate through any number of activities (they're called "cluster" and "leaf" activities). Minimal server transactions, a client state store, and a state update only when the session is closed make it very streamlined.

Here's the deal regarding a foxISAPI service. If one is the kind of developer that depends on VFP selects from DBFs into cursors or selects into a cursor resulting from a DB select, then the project will be sluggish. You can't weight it down with resource hogs! But, should the developer be a devotee to xBASE (low - low point and get or point and set) and minimize appends (normalize optimize) then the project will be crisp and enjoy a high likelyhood of success!

If you can think of a way to XMLHTTP an xml to a foxISAPI COM - let me know - so I can let Rubin know!:-)