It would be a matter of registering a service on a server port, the same way perhaps that IIS would install a HTTP process to port 80. Then when something occurred on that port, the service provider application would step in. It would be the way Foxweb works ... the system gets a request for a file through the port 80 process, IIS perform a "get" of the requested file from the hard drive ... BUT the operating system finds that the FWX extension is registered to FOXWEB and so the request is diverted there. Foxweb finds the script file, processes it, and then "hands" the result to IIS as if it came from the IDE subsystem. Dumb old IIS has no idea that the file was created by Foxweb, it thinks it came from the hard drive platter.

In like fashion, the Foxpro server process would have to register itself with the server on which it runs. It would probably set up a port or the equivalent thereof, so the server could export the service to the network. Then when a request is received on that particular port, the OS simply hands it over to the registered application (presumably a Foxpro app in and of itself) to run the program and perform the query and do whatever is required, before returning the result to the operating system, which would "think" it is data the was "read" from the hard drive paltters and just return it to the requesting network socket as if it were a file.

And yes, it would fill a intermediate need, somewhere between Foxpro in it's current incarnation -- where data is processed locally -- and a larger database, such as Oracle. In a small company, a full-blown SQL database such as Oracle is such overkill, but a "Foxpro Server" would be awesome!