From: Dave Winer (dave@userland.com)
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?
Dave
----- Original Message -----
From: "Mark Baker" <mbaker@cpu2164.adsl.bellglobal.com>
To: <fork@xent.com>
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
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 - 12:40:28 PST