Creating Python Data Server

[David Bolen]

"dsavitsk" <dsavitsk at e-coli.net> writes:

> I am trying to set up client/server system like a database server with
> stored procedures and what not where the procedures are written in python
> (or any other language), live on the server, and that isn't tied to any
> particular database. So the user would press a button on the interface
> sending a signal to the server which would instantiate whatever objects were
> necessary on the server, process the data, and then return the data to the
> client.

It sounds like a good fit for a straight forward RPC (remote procedure
call) or remote component based sort of setup.

Have you considered doing your client in Python as well (you could use
wxPython or Tkinter for a GUI)?  If so, you should definitely look at
XML-RPC.  It's an awfully simple (yet powerful) mechanism for making
remote calls, and absolutely dirt simple if both ends are in Python.
Support also exists for other clients (including a COM client that
could be used from VB).

See http://www.xmlrpc.org and http://www.pythonware.com/products/xmlrpc
for some more info.

Or, if you definitely want to use VB/Delphi for the client, you could
consider implementing your server procedures as COM objects in Python
(with the win32all package), and letting VB access them as it would
other system components - using DCOM in this case for a remote
invocation.

You mentioned in a later post about wanting to have status on the
client over the course of execution - that's really going to come into
play when you define what the remote calls are and/or your component
interface.  You could have one call to trigger the overall procedure,
but just return immediately after starting it, with a handle that you
could use later to check back.  Or you could even multi-thread your
client, and let the server issue its own callback remote calls during
course of execution to the client.

> i though about using apache/mod_python, but i want the user to feel like
> they are running things on their computer, that is, like all of the
> processes are local and the client and server are the same.  Thus http
> doesn't seem to be what i want.

Don't mistake HTTP (the protocol) with clients such as browsers that
may use the protocol.  While it's got warts, HTTP is often a fine
choice as the basic transport mechanism between clients and servers,
particularly as it has a big advantage in getting through firewalls or
other security precautions that are often locked down against anything
besides "web" access.  Besides, at its root, it's just a TCP stream
with some header information, which is fine.

XML-RPC defaults to using HTTP as its own transport, but its all
beneath the covers, so your client/presentation module can do anything
you want.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/