Multiple XML-RPC calls over the same connection?

[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