From: Mark Baker (mbaker@cpu2164.adsl.bellglobal.com)
Date: Sun Dec 31 2000 - 11:45:04 PST
> I think you've noticed something that's very true -- program-to-program
> communication has been going on for a long time, even using HTTP of course,
> and locked-in formats like Apple Events and COM, and not-widely-deployed
> formats like CORBA. There's nothing new in the distributed computing
> formats. Nothing. It's a mere adaptation of an existing philosophy to a new
> transport and encoding.
Sometimes unique adaptations can hit a sweet spot. So while I agree
that the design principals behind HTTP are not new, the combination
of them is most definitely so.
> We've learned from the terrible situation in Web browsers that we must have
> choice. So coming up with some common patterns and simplifying has made it
> possible for us to have choices. I want to be able to switch to Python
> painlessly, or have my content served by a Perl app, with no glitches. For
> that to happen we have to start building. And that has already started. Why
> do people love XML-RPC and SOAP? They do. Read the articles and posts on the
> mail list. It's simple and easy. It shows them how to do it. They needed to
> be shown. And because we use the same formats our stuff is interchangeable
> and in some small way, not in the future, today, more users have choice.
I can't disagree with you at this level. HTTP meets your requirements
there. It shows them some generic application semantics that can be
used to build useful & powerful systems.
A world of SOAP/RPC services is one where, in order to use one, I'd
have to learn an awful lot about the complexities of the individual
APIs I have to call. Does getFoobar() allow me to cache the response?
Is it safe for me to call doThisForMe()? What object am I calling it
on? Is it the same one I called in my previous message? RPC-over-POST
prevents me from using content negotiation, so I can't, for example,
ask for my result in text/plain if I don't happen to do HTML - unless
you want to *reinvent* that on top of RPC. I don't like reinventing.
HTTP provides a common set of guarantees of this sort to *all* services
on the Web. Everybody knows that they can invoke the "get" method on
any service. They also know that "get" won't get them in trouble -
that the server is required to ensure that it doesn't unintentionally
get the user in trouble, such as buying them something. RPC has *none*
of this. It's a free-for-all where there is no commonality to begin
with except for a syntax for expressing method names & arguments.
It is a giant leap backwards, and is completely unnecessary to implement
your (bang-on) vision of the Two Way Web.
> To be powerful the users must have choices. This is one of those times when
> one is ill-served looking to the gorillas for an explanation. Talk to the
> users, they understand. ;->
I think users would be happier being able to reuse their existing Web
services, and not having to rewrite some/all of their stuff in some new
service format. That some don't understand that they can have their
cake and eat it too, is an issue, but one that's dwarfed by those
who continue to use HTTP as it was designed to be used, and will be
happy to find their services fitting into larger composite networks
(aka aggregators) when they arrive.
MB
This archive was generated by hypermail 2b29 : Sun Dec 31 2000 - 11:40:54 PST