XML-RPC, SOAP, and data persistence

[Mark Carter]

"A.M. Kuchling" <amk at amk.ca> wrote in message news:<RtmdnVvXjqjkAxeiRTvUrg at speakeasy.net>...
> On 13 Oct 2003 03:34:47 -0700, 
> 	Mark Carter <cartermark46 at ukmail.com> wrote:
> > to use; which really made an impression on me. But you can't make data
> > persist on the server (not without rolling your own mechanism, at any
> > rate). I'm thinking here about thin clients, where the main process
> > runs on a server.
> 
> I don't follow the connection you're trying to make here.  XML-RPC and SOAP
> are network protocols used for communication between a client and a server;
> what the server or client *do* with the data they receive is up to them and
> not part of the protocol definition.  You simply have to roll your own
> mechanism, or use an existing module such as pickle, ZODB, or an RDBMS.
> 
> --amk

I was thinking in terms of thin clients, where you have to deal with
processes which persist after the call. Maybe you have computationally
intensive simulation software which runs on the server. The client is
a simple GUI that sends events to a process that runs on the server.
Pickling and databases don't really help here - although I suppose
that the server process could periodically dump some useful results
for the client to pick up.

XML-RPC appears to deal with remote procedure calls, but doesn't
address process persistence issues. It has a missing piece in the
"distributed computing" puzzle. Maybe SOAP can do better, because it
has objects. That's mu question.