OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Note from the Troll

[ Lists Home | Date Index | Thread Index ]

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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS