Re: [CNET] Web services -- a 2001 thing?

Date view Thread view Subject view Author view

From: Dave Winer (
Date: Sun Dec 31 2000 - 12:34:36 PST

There are still a lot of disconnects here..

Caching results and renderings are not what this is about.

It's about enabling cross-platform over-the-Internet procedure calls passing
data structures in an intermediate format that are translated to a
programming language's internal data structures invisibly to the programmer.

It's so simple I can't understand what's so controversial about it.

Put it another way: What's your prescription? Withdraw XML-RPC and SOAP and
tell the programmers to ask Mark how to do interapplication communication?
If so, what would you tell them to do?


----- Original Message -----
From: "Mark Baker" <>
To: <>
Sent: Sunday, December 31, 2000 11:45 AM
Subject: Re: [CNET] Web services -- a 2001 thing?

> > 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
> > 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
> > 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
> > choice. So coming up with some common patterns and simplifying has made
> > 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.
> > that to happen we have to start building. And that has already started.
> > do people love XML-RPC and SOAP? They do. Read the articles and posts on
> > mail list. It's simple and easy. It shows them how to do it. They needed
> > be shown. And because we use the same formats our stuff is
> > 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
> > one is ill-served looking to the gorillas for an explanation. Talk to
> > 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

Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sun Dec 31 2000 - 12:40:28 PST