[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Traditional RPC

soap xml rpc differences
Dave Winer wrote:

> BTW, last time I checked HTTP was synchronous.
> Maybe I missed something.

What do you mean by synchronous? Is SMTP asynchronous? If so, so is

 * http://www.prescod.net/asynchhttp.html

I would agree that there are protocols which are deeply asynchronous,
unlike SMTP and HTTP. But most people, when they say asynchronous mean
SMTP and HTTP is just as asynch as SMTP.

> Paul those are good compelling points, had they been raised before we built
> an infrastructure for XML-RPC and SOAP at the script level.
> Earlier this month we finally implemented the top of the stack, something
> called SCNS or Simple Cross-Network Scripting, which makes calling a web
> service as simple as calling a procedure (yes it looks a little different,
> and that's good, imho, people should know when they're making a networked
> call.

REST is admittedly not about cross-network scripting. REST is about
building web services. Here's what I see as the difference: with
cross-network scripting you are trying to hide many of the differences
between making a local call and making a remote call. That's great for
ease of use but it sacrifies a bunch of stuff in terms of
addressability, scalability, peformance and potentially security. I am
totally in favour of this trade-off where it makes sense. I advocate
XML-RPC as a viable alternative to REST with the caveat that I am
nervous about its reliance on "ASCII" and a few other things like that.

REST is about taking the networking issues most seriously. This means
that the interface to networked code is different than to local code.
Not harder, but different. Both client and server have to think
differently when they access networked code. You could paper over the
differences on the client side with an OO library but this might
introduce performance or reliability problems.

In my mind, web services are about doing the sorts of things we couldn't
do with COM or CORBA (otherwise why invent a new buzzword) so I don't
see XML-RPC (or SOAP RPC) as a Web Services technology. I am happy to
promote XML-RPC as a cross-network scripting tool, however, and I have.

> Also I really appreciate the offer to convert Manila-RPC to REST, but let's
> look forward. I'll keep my eye open for an opportunity to use your
> principles in putting together a new service, and I'm sure it'll be easy and
> perform well.
> How does that sound??

Okay, give me a shout when you find something. If it isn't private maybe
we could do the design in the open so that we'll have another example of
applying REST to a problem. But consider that according to my dichotomy
above it probably makes sense to have both a REST and an XML-RPC
interface to some services...you might find that having both in Manila
is a competitive advantage. For instance I'd bet that after we
REST-ified a service you would find that many tools become Manila
clients "for free"...e.g. Emacs, wget, MSWord and Internet Explorer!

 Paul Prescod


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.