Multiple XML-RPC calls over the same connection?

[The Fumigator]

Hi.

I want to be able to create a persistent connection between an XML-RPC
client and server... i.e. I want to be able to login once, carry
out a number of calls and then logout rather than send login info for
every call.

Is there a way to do this with the xml-rpc code in the standard library?

Thanks in advance

[Diez B. Roggisch]

The Fumigator wrote:

Hi.

I want to be able to create a persistent connection between an XML-RPC
client and server... i.e. I want to be able to login once, carry
out a number of calls and then logout rather than send login info
every call.
Is there a way to do this with the xml-rpc code in the standard library?

Not to my knowlegde - and the reason is not python, but the primitiveness of
xmlrpc. It simply doesn't allow for connection state to be associated.

What I do is to create handles, and pass these around - that at least limits
and sort of normalizes the api usage:

proxy = xmlrpclib.Serve r('http://localhost:7080/')
ak = proxy.authentic ate(user, password)
print proxy.some_meth od(ak, argument)

If you want stateful connection, use better IPC-standards, as CORBA - its
way more advanced. SOAP gets attention lately, but its similarily limited
as xmlrpc, and while session state associoated with soap connections is
possible sometimes, its not standarized....
--
Regards,

Diez B. Roggisch

[Jeremy Jones]

The Fumigator wrote:

Hi.

I want to be able to create a persistent connection between an XML-RPC
client and server... i.e. I want to be able to login once, carry
out a number of calls and then logout rather than send login info for
every call.

Is there a way to do this with the xml-rpc code in the standard library?

Thanks in advance

What do you mean by login, logout and login info? Do you mean establish
connection, close connection and <I don't know what would be equivalent
for login info>? Are you wanting a keepalive? If so, I don't know of
how to do that with the standard library. If you've got some sort of
login mechanism on your XMLRPCServer, I would assume you would have to
pass back whatever "key" you received upon login per call.... But I
guess it depends on what you mean.
Jeremy Jones

[Skip Montanaro]

I want to be able to create a persistent connection between an
XML-RPC client and server... i.e. I want to be able to login once,
carry out a number of calls and then logout rather than send login
info for every call. Is there a way to do this with the xml-rpc code in the standard
library?

Look at the multicall capability of the xmlrpclib library. It may do what
you want.

Skip

[Diez B. Roggisch]

> Look at the multicall capability of the xmlrpclib library. It may do what

you want.

Verifying my response I found that, too - but thats more a bundling of calls
together instead of what the op wanted - a way to have some server-side
"cookie" that identifies an incoming call as authenticated. That's not
possible.
--
Regards,

Diez B. Roggisch

[Roger Binns]

Diez B. Roggisch wrote:

a way to have some
server-side "cookie" that identifies an incoming call as
authenticated. That's not possible.

The standard pattern for doing that is having an xmlrpc call
that you supply username/password/other credentials to. It
then responds with a pair of tokens. You then use them as
part of the URL where usernames and passwords are usually
used. For example:

sp=xmlrpclib.Se rverProxy("http ://foo.example.com ")
c1,c2=sp.login( "username", "password", "etc")

sp=xmlrpclib.Se rverProxy("http ://%s:[e-mail] le.com" % (c1,c2))
sp.DoSomething( 1,2)
sp.DoSomethingE lse(3,4)

This will work fine with the current client side xmlrpclib. If
you server side is written in Python then you will need to make
a derived request handler that grabs and verifies the authentication
headers before calling the intended routines (except for the login
function :-)

Roger

[Diez B. Roggisch]

Hi,

The standard pattern for doing that is having an xmlrpc call
that you supply username/password/other credentials to. It
then responds with a pair of tokens. You then use them as
part of the URL where usernames and passwords are usually
used. For example:

sp=xmlrpclib.Se rverProxy("http ://foo.example.com ")
c1,c2=sp.login( "username", "password", "etc")

sp=xmlrpclib.Se rverProxy("http ://%s:[e-mail] le.com" % (c1,c2))
sp.DoSomething( 1,2)
sp.DoSomethingE lse(3,4)

This will work fine with the current client side xmlrpclib. If
you server side is written in Python then you will need to make
a derived request handler that grabs and verifies the authentication
headers before calling the intended routines (except for the login
function :-)

While I have to admit that it is a nice trick, its something I expect beeing
part of a IPC-standard - otherwise, it renders the standard short of beeing
useless.

There are alternatives out there, like corba, which allow for much better
implementations - in terms of ease of use from the api side as well as
performance and interoperabilit y. Having to tweak a standard to make it
work in a certainly common pattern strikes me as awkward. Unfortunately, I
have to use xmlrpc myself as php corba support isn't too good - but I keep
it to a minimum, and its dead ugly...

--
Regards,

Diez B. Roggisch

[Jeremy Bowers]

On Fri, 29 Oct 2004 20:49:50 +0200, Diez B. Roggisch wrote:

While I have to admit that it is a nice trick, its something I expect beeing
part of a IPC-standard - otherwise, it renders the standard short of beeing
useless.

XML-RPC was designed from the get go to be very, very simple, as in
"person skilled in a language ought to be able to get one going in a
matter of hours". It breaks out of that domain, but it is nice to have a
cross-platform RPC mechanism that meets that description. If I want to get
a weather report for zip-code XXXXX, I shouldn't need CORBA.

It isn't useless, but it definitely has established its niche at the lower
end of the scale.

I would point out the XML-RPC is built on HTTP and XML and theoretically
inherits the benefits and disadvantages of both. Specifically, if your
server and client supported it, you should be able to use Cookie: headers
just as you would in HTTP. That would sort of be a grey area in the
standard.

(It's probably about time for XML-RPC 1.1 that seperates the data encoding
from the transport; right now according to the standard they are
intertwined and "XML-RPC over SMTP" or "over Jabber" are meaningless
phrases; those things are just "XML-RPC-like". Then maybe we could allow
various transports to be used more fully, according to the defined
transport; Jabber is another example where the transport has useful
capabilities but they are just thrown away for RPC purposes.)

[Diez B. Roggisch]

XML-RPC was designed from the get go to be very, very simple, as in
"person skilled in a language ought to be able to get one going in a
matter of hours". It breaks out of that domain, but it is nice to have a
cross-platform RPC mechanism that meets that description. If I want to get
a weather report for zip-code XXXXX, I shouldn't need CORBA.
And not much beyond that - more or less all serious applications have _some_
sort of authentication scheme - and thus associating state with a
connection is neccessary in nearly all but the most trivial applications.

And I think we can agree that these days a object orientied interface is how
apis are designed, and thats also beyond the scope of xmlrpc/soap.

Its not so complicated to get a corba server running - at least imho.
Writing a idl is a thing every programmer should be able to do. if its a
well-designed one - well, thats a totally different beast, and beyond rpc
in general - but the inherent clumsiness of xmlrpc/soap based interface
doesn't help here, too.
It isn't useless, but it definitely has established its niche at the lower
end of the scale.

I would point out the XML-RPC is built on HTTP and XML and theoretically
inherits the benefits and disadvantages of both. Specifically, if your
server and client supported it, you should be able to use Cookie: headers
just as you would in HTTP. That would sort of be a grey area in the
standard.

Exactly - its grey. SOAP is grey in that field, too. So it renders e.g. .NET
and AXIS un-interoperable when more than the most trivial tasks are
planned.

I've been in contact with xmlrpc/soap after I became aquainted with corba,
and I have to say that to me its a huge step back in time. But it gets the
attention these days, due to clever marketing and the fact that its based
on xml - something that seems to be a must these days.
--
Regards,

Diez B. Roggisch

[Irmen de Jong]

Diez B. Roggisch wrote:

Exactly - its grey. SOAP is grey in that field, too. So it renders e.g. .NET
and AXIS un-interoperable when more than the most trivial tasks are
planned.
Which is a big pain in the butt! We had to deal with this a few times
in our company, and (if I recall correctly) had to decide on a custom
XML structure that was sent inside a very very basic SOAP wrapper.
(the client wanted SOAP, they got SOAP... :-( )
I've been in contact with xmlrpc/soap after I became aquainted with corba,
and I have to say that to me its a huge step back in time. But it gets the
attention these days, due to clever marketing and the fact that its based
on xml - something that seems to be a must these days.

Back in 2002 I wrote a very extensive article/whitepaper on this subject.
It's available on the OMG website:

http://www.omg.org/news/whitepapers/CORBA_vs_SOAP1.pdf

Interesting stuff inside, if you're into this kind of technology.
(it's PDF, other formats also available on my own website)
--Irmen de Jong