[
Lists Home |
Date Index |
Thread Index
]
OK, I'll try to answer this question, with an analogy.
This week there are hundreds of thousands of people in Utah.
How did they get there?
They came from a lot of different places, but they're all there in Utah now.
Some are watching the Olympics, some are participating, some are covering
it, some are serving hot dogs and beer, some people live there, and some
people have no idea the Olympics are going on at all.
So how did we all get to be on the Web? Similar story.
I can tell you how I got here. I was doing scripting software that turned
into publishing software.
We were already building networks, using Apple Events, which is totally RPC.
So when we ported to Windows in 1996-98, we still needed to network.
Couldn't use Windows networking because that didn't work on the Mac, and
vice versa.
Further, by then, we saw ourselves as Internet developers, largely because
it didn't work well being controlled by the platform vendors.
That led us to XML over HTTP.
We already had systems and practices developed, we were just looking for a
way to encode and transport what we were already doing, but intsead of using
Apple's networking or Microsoft's we wanted to use the Internet.
We had to learn HTTP and XML. Perhaps if we came from somewhere else, we
would have come up with a different approach.
A big thing happened in 1993, when what remained of the desktop software
world, which I was a part of, merged with the Unix world. And of course this
was just a loop, because many of us came from Unix in the first place before
going to desktop computers. I think people often overlook this when
recounting the history of the Internet, as if it were just one thread, when
it was really a joining of many threads, and forking, and re-joining.
About UDDI and WSDL, I am hardly a defender of those bits. I don't think we
need them, and if we did, they're far too complex to gain traction. SOAP
itself can be massaged into a profile that's understandable, so we like
SOAP, but I think the disconnect betw the REST view and the RPC view is that
they come from different places, different points of view, different
experiences.
But we're all one Internet now, no view is more right than the other, imho.
HTH.
Dave
----- Original Message -----
From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
To: "'Dave Winer'" <dave@userland.com>; "Paul Prescod" <paul@prescod.net>;
<xml-dev@lists.xml.org>
Sent: Monday, February 18, 2002 7:03 AM
Subject: RE: [xml-dev] Traditional RPC
> Dave:
>
> I asked earlier that if REST is The Web Way and everyone
> knows that, why are the Web Service baseline specifications
> based on a functional style? As the cannonized defender
> of RPC, can you answer that question? So far, we have a
> lot of material from Paul et al on the REST position
> (no newtonian jokes, please.. :)), but no one has stepped
> forward to defend the web service specification approaches
> other than to say as you have said, the toolkits are there.
>
> So Why Traditional RPC? Why Web Services per UDDI/WSDL/SOAP?
>
> len
>
> -----Original Message-----
> From: Dave Winer [mailto:dave@userland.com]
>
> Paul those are good compelling points, had they been raised before we
built
> an infrastructure for XML-RPC and SOAP at the script level.
>
> Earlier this month we finally implemented the top of the stack, something
> called SCNS or Simple Cross-Network Scripting, which makes calling a web
> service as simple as calling a procedure (yes it looks a little different,
> and that's good, imho, people should know when they're making a networked
> call.
>
> And before someone says Python had it before us, let me say that Python
had
> it before us. ;->
>
> Also I really appreciate the offer to convert Manila-RPC to REST, but
let's
> look forward. I'll keep my eye open for an opportunity to use your
> principles in putting together a new service, and I'm sure it'll be easy
and
> perform well.
>
> How does that sound??
>
> Dave
>
> PS: I'm doing a new centralized app now, it's all web services, and it's a
> good mix of plain old HTTP, XML-RPC and SOAP. And a few other things too.
>
>
>
> ----- Original Message -----
> From: "Paul Prescod" <paul@prescod.net>
> To: <xml-dev@lists.xml.org>
> Sent: Sunday, February 17, 2002 2:11 PM
> Subject: Re: [xml-dev] Traditional RPC
>
>
> > Dave Winer wrote:
> > >
> > > I've been following this debate from the sidelines and finally thought
> it
> > > was time to chime in.
> > >
> > > The big difference between "Traditional RPC" (whatever that means) and
> REST
> > > is that there are toolkits for T-RPC for every language and
environment
> > > known to man. [1] [2]
> >
> > REST is a technique, not a bit of software. You've already built a
> > business around sophisticated uses of that technique. The fundamental
> > idea is that every important data object should have an address so that
> > it can be referenced. When you apply that technique to human
> > communications you get Blogging. When you apply it to machine to machine
> > communications you get a much more powerful type of web services.
> >
> > As applied concretely, REST consists two things: URIs and HTTP. When it
> > is applied to machine to machine problems it usually also consists of
> > XML. Any language that has support for these three technologies has
> > support for REST in general and XML+REST in particular. So support for
> > REST is required before XML-RPC can be implemented.
> >
> > Web Bugs in XLM is an excellent application of REST:
> >
> > http://scriptingnews.userland.com/backissues/2002/02/17#webBugsInXml
> >
> > Note how I referred to it with a URI. (my only suggestion is to make the
> > "ping" a POST, not a GET to use HTTP semantics correctly and avoid
> > miscounts due to caching). Another interesting thing about this
> > application is that it is a perfect example of Asynchronous HTTP, which
> > many people mistakenly claim is difficult or impossible.
> >
> > > REST seems to have found a home in debates on XML-geek mail lists, and
> > > occasionally at conferences and on O'Reilly's websites.
> >
> > Oh yeah, and on every website that exists.
> >
> > > If you want to have a revolution, our software will adapt [3]
perfectly
> to
> > > it, let's get some apps, and let's rock.
> >
> > Your software doesn't really have to adapt. You don't need new apps.
> > Meerkat uses REST heavily. When it wants to get information from
> > scripting news to aggregate it, it doesn't call an RPC API, does it? It
> > just uses HTTP to fetch some XML. When I want to integrate some Meerkat
> > information into my site I also don't have to call an RPC API.
> >
> > I just do this:
> >
> > http://www.oreillynet.com/meerkat/?_fl=xml&s=Dave+Winer
> >
> > I think it is amazing how I can refer to this resource in a totally
> > programming-language and environment independent way. Whereas, let's
> > consider the RPC equivalent:
> >
> > ServerProxy("http://www.oreillynet.com/meerkat";).GetArticles("Dave
> > Winer")
> >
> > This isn't syntactically correct Perl or C++ or ..., so it has to be
> > translated to each language. I can't use it in a standard web browser.
> > Wget doesn't understand it. I can't make RDF assertions to it. I can't
> > reference it (directly) in a blog. I can't apply an XSLT transformation
> > to it. I can't incorporate it by reference from another XML document. In
> > other words, by hiding it behind RPC I've lost all of the advantages of
> > this World Wide Web we've built. For the most part, REST is just about
> > *NOT* doing that. Keep things in the one, global namespace that we
> > share. Don't invent new, proprietary namespaces like "getArticles" and
> > "getStockQuotes". That's why REST requires no new technologies. It is
> > about NOT applying "LAN habits" to the Internet.
> >
> > Now in Python I can convert the URI to a DOM like so:
> >
> > url = "http://www.oreillynet.com/meerkat/?_fl=xml&s=Dave+Winer";
> > data = urllib.urlopen(url)
> > dom = minidom.parse(data)
> >
> > If the data used a well-known serialization format like XML-RPC's or
> > MIME-RPC's or the SOAP Encoding then I would deserialize it directly
> > instead of using a DOM, and it would be essentially as easy to use as
> > XML-RPC:
> >
> > url = "http://www.oreillynet.com/meerkat/?_fl=xml&s=Dave+Winer";
> > data = xmlrpcdecode(urllib.urlopen(url))
> >
> > If you're interested, we can work together on REST-ifying the Manila API
> > or any other API of your choice. I'll do most of the work, you just have
> > to help me interpret the original API. When we're done, you can compare
> > the costs and benefits of the two APIs. You can decide whether or not to
> > implement the REST version in Frontier based on those costs and
> > benefits.
> >
> > Paul Prescod
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://lists.xml.org/ob/adm.pl>
> >
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
|
