Summary of recent XML-RPC developments

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

Summary of recent XML-RPC developments

Author: Dave Winer

Posted: 9/7/1999; 6:49:47 AM

Topic: Summary of recent XML-RPC developments

Msg #: 10661

Prev/Next: 10660 / 10662

There were many new developments in XML-RPC over the long holiday weekend, and I expect there will be many more over the coming weeks. The purpose of this posting is to summarize what has been accomplished and speculate on what the immediate future holds.
Most of what's happened is in relation to a high-level spec that says what a discussion group interface looks like. This builds on a lower-level spec, that explains what the formatting of an XML-RPC message is and what a returned message looks like. None of this will make sense, at a technical plumbing level, until you understand the two specs.
But you don't have to start from scratch. There are already server-side implementations you can use, for Java, Python, Perl, Tcl, ASP, PHP, and Zope. They are linked to from the XML-RPC.COM home page.

Why??
The advantage of wiring up a discussion server is that thru common interfaces, people are able to connect up scriptable text editors to the web, working around the limited abilities of s in web browsers. Once you have the ability to use a modern editor to write for the web you won't want to go back. And it only makes sense to do this with open interfaces. Users of the web come from all platforms. It should be possible to use Word to edit a DG message on Deja, even though their servers are Linux. And it should be possible to use Emacs to edit messages on a UserLand server even though we're running NT. Common interfaces are key here. <h4><a name="3"><a href="http://www.xmlrpc.com/discuss/msgReader$394">Tim Lundeen</a></a></h4> Tim and his company <a href="http://www.webcrossing.com/">Web Crossing</a> are working on compatible XML-RPC interfaces for their very widely deployed discussion group software, also called Web Crossing. Now that Tim is on board, we have a credible story that the DG interface is a standard. To really nail it, it would be great to get support from other DG software vendors and site operators. The two biggies here would be Deja.Com and SlashDot.Org. If anyone knows people in development roles at either place, please point them to this message. On re-reading this, I realize that I would be equally happy to get support from SquishDot, LinuxToday and FirstClass. If you have suggestions for others we should evangelize, post a response to this message. Any site where users openly contribute essays is a likely candidate for supporting this protocol. Walter Purvis says: "For DGs, you should also evangelize eGroups (my favorite for simple interfaces), PowWow, Delphi, WebBoard, and of course the major portals' discussion groups like Yahoo Clubs, AOL forums, etc. (the portals are economically disinclined to support non-browser editing, but you never know.)" <h4><a name="4"><a href="http://frontier.userland.com/discuss/msgReader$1199">Editing DG messages with Frontier</a></a></h4> We have provided a workstation interface, called suites.dg, that allows Frontier's outliner to be used to create and edit DG messages. This <a href="http://frontier.userland.com/discuss/msgReader$1271">release</a>, as all releases, includes full source code, which you can <a href="http://frontier.userland.com/discuss/enclosures/view$1271">browse</a> via the web even if you don't have Frontier. This is our test case app. It should be possible to use this editor to write and edit stories for any compatible server. <h4><a name="5">Screen shot, list of stories</a></h4> Here's a screen shot showing how I wrote and edited this message. <img src="http://www.outliners.com/images/frontier6/outlinerEssay.gif"> And as proof of the power of this idea, here's a <a href="http://www.xmlrpc.com/discuss/msgReader$351">list of stories</a> I've written using this interface. Do they look or read like web postings? I think clearly not. As the author I can tell you why. It's because I can write in a comfortable editing environment with all the tools I've become accustomed to. Undo. Find and replace. The HTML menu. Expand-collapse. Reorganizing and sorting. All the stuff we'll wait a dozen years for MSIE to support. ;-> <h4><a name="6"><a href="http://www.xmlrpc.com/discuss/msgReader$388">Enclosures</a></a></h4> In addition to providing interfaces for adding a new message, changing an existing message and editing a message, we now have an interface that allows a user to add an enclosure to a DG message thru XML-RPC. The <a href="http://www.xmlrpc.com/discuss/msgReader$181">spec</a> has been updated, and sample code for Frontier has been shipped as part of suites.dg. <h4><a name="7"><a href="http://www.xmlrpc.com/discuss/msgReader$354">Hooking into the story flow</a></a></h4> Now shift your focus all the way to the other end of the pipe. We've been steadily adding new interfaces to the backend, and this weekend we blew it totally open, perhaps anti-climactically. We have an aggregation <a href="http://my.userland.com/">engine</a> here that reads a collection of hundreds of RSS files every hour, churning them into a nice story flow database. That database is now fully accessible via XML-RPC. This should make new user interfaces possible on other people's servers. We plan to release sample code for Zope, unless someone beats us to it. (Hint to Eric.) <h4><a name="8">Intellectual property</a></h4> Tim Lundeen raised an issue with me privately that I now want to open for discussion. He's concerned about the possibility that UserLand may claim ownership of the XML-RPC specification in a way that could hurt the viability of XML-RPC as a networking standard. I asked him for a scenario that explains his concern. He envisioned UserLand being acquired, and that the acquirer would attempt to impose a tariff on products that implement the specification. His concern is understandable. First the recent experience with GIFs and Unisys has left a bad taste in the web developer world. Second, I have a recent experience, the acqusition of Alexa by Amazon, where there probably was a complete reversal on a promise made by Netscape and Alexa. It's hard to check this out because Netscape was acquired too. Acquisitions happen, and while people seem to trust me, it's understandable that they might not trust me not to sell out. In which case they would have to trust the successors, and you don't even know who they might be. (We have no plans on being acquired, btw.) So we will do something to make the XML-RPC irrevocably in the public domain. The question is how to express that. We want to retain a copyright on the spec itself. I don't understand or believe in public domain writing. But any implementation of the spec is completely free. You are free to even be incompatible, but I want to be sure that compatibility means something. And you may quote the spec liberally, on a fair use basis. If you're implementing the spec, I don't want anything to stand in your way. Thoughtful suggestions are welcome. <h4><a name="9">Who do you write for?</a></h4> People ask who I write for. I say I used to write for Wired. That impresses them. And then I say "I write for the Internet." Eyes glaze over. More and more over time that will mean more and more. It's a political statement and it's a technological one. <h4><a name="10">Heads up</a></h4> Finally, I have reason to believe that there will be another XML-RPC specification launched this month. I expect it to be controversial, but I hope people listen and think before they react. I believe that support for the *idea* of XML-over-HTTP distributed computing is very important. We learned in the evolution of interapplication communication on the Mac in the early 90s that the format of the plumbing matters very little. What matters is useable support for the plumbing in applications. We didn't care if apps used Apple's technology, or Microsoft's, or cooked their own, as long as there was a way to hide the differences behind a common interface, scripters benefited. The same thing will be true in the XML-RPC space. Every big company will probably launch their own specification. Implementors should be aware of this, and should plan their software interfaces accordingly. Expect wiring-level incompatibility and you won't be surprised. I can't say more at this time about this subject, but stay tuned, we'll have the news here first on UserLand. <hr>There are responses to this message:<ul><li> <a href="msg010670.html">Re: Summary of recent XML-RPC developments</a>, David Theige, 9/7/1999; 8:26:37 AM<li> <a href="msg010672.html">Re: Summary of recent XML-RPC developments</a>, Sergio Fanchiotti , 9/7/1999; 9:59:26 AM<li> <a href="msg010676.html">Re: Summary of recent XML-RPC developments</a>, Mike Moran, 9/7/1999; 10:41:50 AM<li> <a href="msg010677.html">Re: Summary of recent XML-RPC developments</a>, Leonard Rosenthol, 9/7/1999; 10:43:36 AM<li> <a href="msg010687.html">Re: Summary of recent XML-RPC developments</a>, Bryant Durrell, 9/7/1999; 12:33:45 PM<li> <a href="msg010701.html">Re: Summary of recent XML-RPC developments</a>, John Brewer, 9/7/1999; 3:21:04 PM<li> <a href="msg010703.html">Re: Summary of recent XML-RPC developments</a>, John Brewer, 9/7/1999; 3:34:45 PM</ul> <hr>This page was archived on 6/13/2001; 4:52:27 PM. © Copyright 1998-2001 <a href="http://www.userland.com/">UserLand Software</a>, Inc. </blockquote></blockquote> </body> </html>

Author:	Dave Winer
Posted:	9/7/1999; 6:49:47 AM
Topic:	Summary of recent XML-RPC developments
Msg #:	10661
Prev/Next:	10660 / 10662