XML-RPC, SOAP, and data persistence

[Mark Carter]

I had a play with XML-RPC the other day, and it seemed really simple
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.

Is there any free solution to this problem? Is SOAP the answer?

[A.M. Kuchling]

On 13 Oct 2003 03:34:47 -0700,
Mark Carter <ca**********@u kmail.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

[Rodrigo Benenson]

ca**********@uk mail.com (Mark Carter) wrote in message news:<d3******* *************** ***@posting.goo gle.com>...

I had a play with XML-RPC the other day, and it seemed really simple
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.

Is there any free solution to this problem? Is SOAP the answer?

You can use Pickle or look at Twistedmatrix.c om for a full featured solution.

RodrigoB.

[Mark Carter]

"A.M. Kuchling" <am*@amk.ca> wrote in message news:<Rt******* *************@s peakeasy.net>.. .

On 13 Oct 2003 03:34:47 -0700,
Mark Carter <ca**********@u kmail.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
"distribute d computing" puzzle. Maybe SOAP can do better, because it
has objects. That's mu question.

[Irmen de Jong]

Mark Carter wrote:

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

I strongly recommend you to takea look at Pyro,
http://pyro.sourceforge.net

With a few extra lines of code you can make Python
objects in your application remotely accessible as
if they were just regular local objects.

Pyro server objects are long running processes that
sit there and wait till someone invokes methods on
them. You can create per-user objects instances too.

Have a look!

--Irmen de Jong

PS Pyro is only suitable for a 100% python environment.
(both client and server are written in Python).

[A.M. Kuchling]

On 14 Oct 2003 03:20:29 -0700,
Mark Carter <ca**********@u kmail.com> wrote:

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

No, SOAP doesn't address persistence any more than XML-RPC does; both
implement remote procedure calls with more or fewer bells and whistles. SOAP
has the additional disadvantage that the spec is very complicated, making it
hard for Python implementations to be up-to-date.

--amk

[Mark Carter]

"A.M. Kuchling" <am*@amk.ca> wrote in message

No, SOAP doesn't address persistence any more than XML-RPC does; both
implement remote procedure calls with more or fewer bells and whistles. SOAP
has the additional disadvantage that the spec is very complicated, making it
hard for Python implementations to be up-to-date.

Thanks. I once saw a thick book on XML at the office, but soon put it
back as there was an aweful lot to it. But looking at XML-RPC, I saw
how easy it was to implement RPCs. It's so fuss-free and generic that
its difficult to imagine wanting to use any other mechanism.

Kinda makes you wonder what the whole point of .Net is.

The above comments are, of course, off-the-cuff remarks.