Next steps in XML-RPC
Monday, September 20, 1999 by Dave Winer.
Thanks to Microsoft there's new support for XML-RPC. This is great! Recalling the early years of DaveNet when I asked Apple to tune into the Internet, contrast that with what Microsoft has done.
It was really simple, we made a proposal, publicly, thru this column, they accepted it, and now Windows networking is open to scripting from other platforms.
As far as I'm concerned this is the best model for working together. No non-disclosure agreements. A simple proposal, a timely response.
Microsoft didn't have to work with us. No one would have asked Bill Gates "Why don't you work with UserLand?" No analyst or venture capitalist would have ever asked the question either.
But Microsoft is an opportunistic company. Thanks, that's all I ever wanted Apple to be.
So now that we have an agreement on bridges between scripting environments, the next question is what kind of traffic do we send across those bridges?
There will be lots of answers to the question. It's like asking what kinds of software do you want to run on your desktop, or what kind of website can you create with HTML.
What kind of cooking to you like, Italian, French or Chinese? All three require kitchens and tables, waiters and utensils.
Every company that develops net software will have their own answer to this question, although there will be areas of common interest, and this is where standards become important, especially for users.
My company's purpose is to flow news thru the web. At the beginning of the process, news is a story with pictures that's entered into a web browser or thru specially adapted text editing tools.
The browser interface is important so that members of the editorial team can add a story or comment from any web-enabled desktop. The text editing interface, which depends on XML-RPC, is for real writing. The goal is to bring the web to professional writing tools, to eliminate complexity and to empower writers.
With support for XML-RPC in Windows, we'll be connected to the most popular writing tools. We're working with other developers to build the same capability into the Macintosh OS.
We released the specification for this protocol in August, and encourage all developers of content management systems, discussion group software, and desktop editing tools, to join us in implementing this interface:
Further, we're learning that this interface has applications in instant messaging. Imagine checking an option to record a conversation to a website, where you can then use convenient editing tools to tweak it up for publication. This application is definitely on our horizon now.
This weekend we released an XML-RPC interface for preferences flow.
To understand where this is useful, imagine you're running a website across several machines, not necessarily on the same local area network. Further, they might not even be running the same content management software.
If some or all of the servers are churning out dynamic content according to user preferences, you run into the problem of preferences flow. We needed this on UserLand.Com, as does the developer of every site with more than modest flow.
I imagine that every application server vendor is building their own solution to this problem, but at UserLand we chose to be open, our purpose is to not just create an important feature for our customers, but to have our software play well in mixed environments.
Users should want standards because they protect their investment. Say you spent $2 million on a content server, but next year a more powerful system comes along, priced more reasonably. You'd probably want to be able to flip a switch and start using the new system, while still running the old one. By building on standards, all vendors can offer that kind of compatibility. Users should be asking the question of their vendors. "What if something better comes along? Do I have to stay with you?" Listen carefully to the answer.
At UserLand we have so much confidence in our product that we offer open interfaces at every point of connection. This means you could use PHP to do the preferences management and use Frontier as an affiliate server. Or deploy Frontier as the preferences hub and render content with Cold Fusion, ASP, Zope or whatever you like. If we agree on how to make customization features configurable in a standard way, users get more choice. That's the strongest selling point any vendor can offer -- choice.
So, if you like this idea, please send the following pointer to your favorite application server vendor and ask them, for me, to consider supporting open preferences flow thru XML-RPC:
In the next two weeks we will do a similar treatment for syndicated story flow thru XML-RPC.
This is the other end of the pipe in content management software. Once a story has appeared on the web, how do interested people find out about it? This is RSS, the syndication format we're working on with Netscape.
The story flow interface defines how an affiliate site hooks into the flow of new stories. From there, they can use the flow to add headlines to their home page, or flow the text thru a search engine, or combine the flow of several sites into a single site (this is especially valuable on corporate intranets and in education). And there probably are dozens of other useful ways to flow the links to interested readers.
Another very valuable area is XML-RPC-based interfaces that allow content management systems and search engines to work together at a higher-level. We could tell a search engine a lot about the documents we manage. For example, we could eliminate the confusing template information that the search engines receive when they crawl our sites thru HTTP and scarf bits of information about our content by reading the HTML.
Thru XML-RPC we can feed them the content itself, and update them whenever it changes. In 1999 much higher-level search engines are possible. In 2000, it will get higher still. We already have working technology in this area, and in the next few weeks we will formally and openly show how it works.
With Microsoft's support we can ask for more support.
I want XML-RPC to be owned by the Internet, not by any set of companies. It's too good to just have Microsoft, Developmentor and UserLand behind it.
I want Red Hat and Caldera, VA Systems, Novell and Sun, IBM and Apple, O'Reilly, Allaire, Digital Creations, WebMethods, DataChannel, Netgravity, Carmen's Headline Viewer, Conxion, AOL, Amazon, eBay, Excite, Google and Yahoo, Gomez and Epinions, IETF and W3C, Stanford and Dartmouth, Deja and WebCrossing, Jakob Nielsen, Linus Torvalds, Eric S. Raymond, Bill Joy, Tim Berners-Lee, Ben Rosen, Esther Dyson, Tim Bray, Guy Kawasaki and Mitch Kapor, Python, Perl, Tcl, AppleScript, Scriptics and ActiveState, The Motley Fool and MacWEEK, Knight-Ridder, Salon, Red Herring, Upside, CNN, MSNBC, Wired, SlashDot, SquishDot and LinuxToday. XML.Com and XMLTree.Com. Dell and Gateway, Invisible Worlds, Inktomi, Vignette, Interwoven, ATG, Broadvision, Lumeria, iSyndicate, Marimba, Adobe, Macromedia, Quark, Bare Bones, Homestead and on and on and on and on.
And I'll not forget Microsoft, our friend, and a diverse multi-national company with lots of users. To everyone who is reading this at Microsoft, let's wire up your applications to the web. The specifications are on the IETF website and XML-RPC.COM. The more cross-network connections your software has the more possible uses it has too.
This is far too big a market for UserLand, and I believe, too big for Microsoft as well. Let's build services that connect our net-based offerings at higher and higher levels. Let's turn the Internet into a powerful Turing Machine. Microsoft has helped. We don't need everyone in the loop, just the most visionary, ambitious and entrepreneurial developers.
PS: The Turing Machine is a mathematical model for computing defined by British mathematician Alan Turing in 1936 at Princeton. When an engineer says "It's just a Turing Machine," that means that it's just a computer. Being a Turing Machine is a good thing. Is the web a Turing Machine? Half and half. Eventually it will be fully Turing.