Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Traditional RPC
 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: * 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
