Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Note from the Troll
 Alaric Snell wrote: >... > > But you can never escape the old problem of the two armies; if you send a > single request packet, never hear anything back, and retransmit for days > without ever hearing back, you still don't know if the remote server got the > packet or not. That's a brutal problem and it is a perfect example why it would be incredibly wasteful to write code designed for the local case as if it were designed for use over a network...which is what it sounds to me like you were proposing when you started talking about trappable SEGV signals. It simply doesn't make sense to write local code as if it were remote code nor is vice versa reasonable. > Programming languages that have exceptions don't need to hide the network > when doing RPC. The RPC calls can just throw an extra RemoteException if > there's a networking problem, and bob's your uncle; we're exposing the > potential unreliability of the network, and nobody every said that any method > call has to be particularly fast anyway so we've nothing to hide in the > latency department! The question isn't whether the reliability is exposed through the API. The question is whether the application and API are *architected* around the potential for failure and latency. If they are, then they will be too much of a hassle for local use. This is all documented carefully in "A Note On Distributed Computing". You can certainly build decent protocols on top of RPC -- but only by sacrificing the very thing that made RPC so nice: the fact that it makes remote procedure calls look like local ones! An HTTP defined on top of RPC would still be HTTP. But HTTP API calls do not look much like procedure calls. >... Not even using HTTP! I agree, though, that forcing the RPCs to be hard > to do (by requiring conversion of your data to XML and poking it into HTTP, > many lines of code) will force people to try to do it less, thus removing the > above problem. But more to the point, HTTP is optimized for handling networking issues like lost messages and latency. It defines idempotent methods carefully (these help reliability). It defines cachable methods carefully (these help latency). > And as for the REST argument that 'there are only a few methods, GET and POST > and others'... I think it's wrong to say that GET and POST are methods in the > same sense that getName () and getAge () are; in HTTP you would do GETs on > seperate URLs for the name and the age, or GET a single URL that returns both > name and age. In no way has GET replaced getName and getAge. HTTP's GET and > POST and so on correspond more to an RPC protocol's' INVOKE' operation than > to the application-level getName () and getAge (). You can surround the issue with logical sophistry but it doesn't change the core, central fact: any "application" in the world can invoke GET on any URI without previous negotiation. There are dozens of standards and tools with support for that built in, starting with HTML, through XLink, through the semantic web technologies, through XSLT and XPointer, through the stylesheet PI, through Microsoft Office (including, I'd wager XDocs), through caches and browsers. That will never be true for getName and getAge. That makes GET inherently superior to getName and getAge. Even if one does not buy the entire REST argument, it amazes me that there are still people out there arguing that it is better to segment the namespace rather than have a single unified namespace for retrieving all information. You talk about reinventing wheels and learning from the past. Surely the ONE THING we learned from the massive success of the Web is that there should be a single namespace. 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
|
|||||||||
