Archive of UserLand's first discussion group, started October 5, 1998.

scriptingNews outline for 5/18/2000

Author:Dave Winer
Posted:5/18/2000; 10:23:30 AM
Topic:scriptingNews outline for 5/18/2000
Msg #:17376
Prev/Next:17375 / 17377

Friday's work

Due to strangeness in time-zones, I'm writing this on Friday morning, but it's still Thursday night back at my website. So forgive the awkwardness as I prepare for today's presentations. It's going to be a busy hectic day. I'm going to do as much preparation as I can (just one hour, no coffee yet) and then do what I always do -- wing it!

The first panel (9 -- 10:30AM)

Dave Winer, UserLand, on the state of XML-RPC.

Henrik Frystyk Nielsen of Microsoft, on the state of SOAP. (Henrik graciously agreed to substitute for Don Box, who couldn't make it to Amsterdam.)

Jim Flanagan, Collective Technologies, Authenticated XML-RPC.

The State of XML-RPC

First, who am I? I'm an app developer. That's how I view these things. We can have more than one protocol for connecting apps over the Internet as long as they're roughly functionally equivalent. We were able to flatten out the differences between our IAC toolkit and Apple's in the early 90s, and should be able to do the same with the various RPC protocols that are appearing on the Web in the early 2000s.

So it's my job to explain where XML-RPC is today. First, the spec is stable, it hasn't changed in well over a year. This is a good thing, because when people talk about XML-RPC it's very clear what that is. That is not true of SOAP, which has been morphing and changing, and in all likelihood will continue to do so.

There is broad support for XML-RPC in the developer world. Implementations are available for Frontier, Python, Java, Perl, Tcl, ASP, COM, PHP, Zope, AppleScript.

Applications being built in XML-RPC include search engine to CMS connections, prefs distribution, software updates, and many private server-to-server applications.

Open specs that build on XML-RPC are the key to its future. It's just a beginning, but I believe a solid one.

XML-RPC provides power equivalent to a C interface, procedures with parameters that return results. Support for the common types, strings, numbers, binary info, lists, structures. It's beautifully recursive, and (to me) surprising how well it covers the capabilities of the popular scripting environments. (Credit for this goes to Mohsen, who clearly had an encyclopedic understanding of the capabilities of various scripting environments.)

Where SOAP is the protocol that the big technology companies are agreeing on, XML-RPC tends to have more support among individual developers, small companies, open source developers. In fact most of the XML-RPC implementations are open source.

While UserLand is often identified as the owner or creator of XML-RPC, this is not accurate. The XML-RPC specification is copyrighted, but on very liberal terms, inspired by the IETF copyright. and while UserLand participated in the creation of XML-RPC, some of the most brilliant ideas came from people at Microsoft, and Fredrik Lundh of PythonWare played a key role in shaking out the spec, as he did the second implementation in Python (of course).

The future of XML-RPC? Where do you want to go today? ";->"

We need a validation suite. When I get back to California, I hope to start a project to write a "super stress" web application that will call a server, ask it to perform a standard set of operations and compare results, and rate the implementation on its compatibility. This way we can be sure there is one and only one XML-RPC spec. This app will make regression testing a part of the XML-RPC culture, making it possible to go forward.

If new features are added to XML-RPC, they will work in all popular environments currently supported. There will never be an XML-RPC that is not least-common-denominator. SOAP is the proper place to bring ideas that advance the state of the art in distributed computing over the Internet. The purpose of XML-RPC is to provide a deployment vehicle while SOAP is fluxing.

Evangelism. All SOAP implementors are encouraged to also implement support for XML-RPC. This will give your applications the broadest possible compatibility, and will keep the pressure on the SOAP process to move forward as quickly as it possibly can.

Security and best-practices. The XML-RPC community can and should develop a set of recommendations for developers who build Web applications, perhaps establishing a review process for security holes and unclear and overly complex applications.

Finally, I hope that the spirit of the XML-RPC community continues to be collegial, respectful, friendly, optimistic and low-tech. So far this group of developers has distinguished itself for its focus on good technology, empowerment of each other, and almost no religious flamewars. This is truly amazing because the XML-RPC community spans multiple operating systems, economic systems, languages, and geography. Imho, it represents the best of the Web, and it's a total honor to be part of such a community.

Background: The Two-Way Web, spec, debugger.

Thursday's notes

Wired: "The protocol wonks of the World Wide Web Consortium get impassioned debating the merits of transport layers and the relative benefits of XML-RPC versus SOAP."

4/24/95: "Anna Chavez, the anchor on KGO-TV said: 'Isn't it great Pete! No matter who wins, *we* win!' Imagine her putting both of her index fingers to her cheeks, twisting them slightly and swaying her head from side to side. I groaned when I heard her say it. 'This is not good.'"

David Galbraith from Moreover.Com on JIT-SEs: "The aim at Moreover has always been to move towards this. We have implemented a search feature which returns xml from the 1500 sources that we aggregate near realtime data from." BTW, David is here in Amsterdam, right across the ailse from me, updating his site, while Andre updates his. We're all going to dinner in a few minutes. This is weird. And weird is good.

David Brown of ZopeFish asks: "Should I ditch the grand scheme of ZopeFish and instead work on integrating the ZopeFish technology (specifically the Pike integration) into the Zope Portal Toolkit?"

Pictures from San Jose on

Busy day. Tomorrow will be more busy, we're doing a half-day distributed computing track and in the afternoon I'll present Manila on Dale Dougherty's web publishing track. Decided to spend the weekend in Amsterdam, there hasn't been enough time to actually be here. Then I'll figure out where to go next.

There are responses to this message:

This page was archived on 6/13/2001; 4:55:13 PM.

© Copyright 1998-2001 UserLand Software, Inc.