|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
AP: Napster Still Full of Users. Red Herring: "Over the past year, Loudcloud's head count jumped from 71 to 586." From the Rube Goldberg Would Like This Department, Bill Kearney has AIM connected to the Web through Radio. Dylan Tweney: "Copyright law is fast becoming irrelevant, thanks to the Internet. It's time to start figuring out how to replace it with something that works." A Jabber developer who's exploring SOAP. Interesting combo. Freshmeat: "Does working on the adult part of the net mean I'm a scumbag?" More RSS sources on Newsfeeds. Seattle Wireless is "a not-for-profit project to develop a community wireless network in Seattle and end recurrent telco fees." Simon Fell is doing a WSDL validator. I just spent a half-hour trawling around through search results on WSDL on Google, and scanned a few articles looking for a concise newbies explanation of what WSDL is and why a script writer would be interested in it. I found a lot of puffing and politics, but very little in the way of motivation. What is it for? Who is supposed to create the WSDL? What are they supposed to do? I think these people whoever they are, don't have a clue how Web apps are deployed. I drop a script in a folder basically and call it. If I want someone else to call it I write a page of docs. If I want to remember why I did it, I put comments in the code, and if I want other people to understand why I did it, I put those comments in the docs. It's work, but I understand that kind of work. I have no idea what these folks are up to. Now it could be just the workflow stuff I wrote about last weekend, if you yell at me, that's OK, but be sure to explain why anyone would want to take the time to do WSDL and where can I go to find out what the heck it is. End of rant. (Inspired by the XML Bastard.) Thanks to Simon Fell for the thoughtful response to my What is WSDL question. I guess the main benefit is that you can generate stubs, once there is some WSDL content to parse, automatically; and the main problem is that the language is underspecified so it's not possible at this time to support WSDL and when it's finished being spec'd it will be quite complex because it already is quite complex. I wonder if any of the BigCo's are getting the message. The complexity in XML has gotten out of hand. I've been talking lately about RISX, an acronym for Reduced Instruction Set XML. Factor and trim until you can go no further. The Google XMLization is an overboard example of this, they use one-letter element names and no schema, RDF or namespaces. But I bet I could figure it out without any docs in about 20 minutes. (Whether they want me to is another question.) Other RISX formats: NASDAQ's stock quote service, RSS, OPML, XML-RPC.  There's a difference between the kind of XML a theoretician produces, someone who isn't concerned about implementing or supporting the stuff, a wonk with a PHB, someone who likes to fly around the world to committee meetings, and takes sabbaticals and long vacations; and the kind of XML an engineer designs, a 24-by-7 guy (with a beeper) who never gets to take a vacation, who knows that he's going to have to pass the code off to someone else, who's going to break it if he doesn't understand what the $*@#$ is going on. I obviously am in the latter category. (And even if you get the code right for the committee-designed spec, they're inevitably going to change their minds and produce an incompatible version of the format and use the same name, so everyone will think your code is broken.)I also spent a half hour on the phone yesterday with a friend who's on the UDDI committee. Same story, of course. Simon gets the closer: "If WSDL in its current form continues to be the only way to manage metadata about web services, then the future for current SOAP community looks bleak." A golden spike  I've come to know Paul Kulchenko through his frequent posts to the SOAP weblog, announcing new versions of his SOAP for Perl. He's steadily improved the software over quite a few months, this is a good sign, the lights are on over there. Paul has also been maintaining a list of SOAP 1.1 implementations. Paul's list was more complete than mine, so I asked if he could produce an OPML version so I could include it in my directory. There were a couple of glitches on both sides, but we worked them out quickly, and he's got it working. I linked it in. And here's the new implementations page on SoapWare.Org. Scroll to the bottom. Paul is the editor. And if you suggest a link, the email goes to him. When he updates his OPML file, within an hour our server will reload its cache. This is the first time I've used our directory software, developed in late Y2K, to bootstrap a community. It comes at a time when the various SOAP communities are finding out about each other. (I hope!) It's a good place for OPML to get exercised, people in various SOAP worlds are knowledgable about XML, and they're do-ers, not talkers. That's what it takes to get bootstraps going. BTW, there's an OPML developers mail list. SOAP in critical section I had an interesting conversation with a couple of Gnutella developers at the P2P conf in Feb. They like XML-RPC and could see the difference between it and the broader SOAP protocol. I told them the story of how it forked from SOAP in 1998. This is something I couldn't talk about publicly at the time, because Microsoft's involvement was up to them to announce. The Gnutella guys said it was a good thing I did the fork at the time when the ideas were so simple, before it went through the political process inside Microsoft. Well, something like that is happening again. When it's done, I hope Microsoft and the other big companies live up to the spirit of yesterday's piece. Through no fault of any single person, the natural way to proceed at a big companies is not necessarily the open way. I don't want to scare anyone but it is a little scary, SOAP is in what we call a "critical section" in programming, what happens between now and the summer will determine if it's a revolution in open software design. The key here, imho, is for everyone who has a SOAP implementation that they're interested in validating against other implementations do it in the open, with public servers, outside firewalls. Let the community work on this, not the companies. There's a lot of heat right now, but Microsoft is again, excelling at listening. This is their biggest strength, and in my experience, is unique in this industry. What happens next must tap into the minds of the people who are implementing SOAP, some of whom are talented hard-working individuals, and others are small companies hoping to make a name for themselves by making an excellent technical contribution. There are medium-size companies, and others are huge, the largest technology companies in the world. They all deserve a chance to define what interop means for SOAP, we must have the expertise of all of them if it's going to be a market with lots of independent development. How these things gets started forms the genetic encoding of the community. At some point the standard-setting must stop, so it's safe to develop applications. The consensus seems to me, to be that that time is getting close. 9/25/99: Dave's Story of SOAP. Random news bits Forbes: "Yahoo's chances of remaining independent are beginning to look slim to none." AP: Taliban Destroys Ancient Buddhas. "The two Buddhas, 175 feet and 120 feet tall, are hewn from the side of a mountain in Bamiyan. The taller statue is thought to be thought to be the world's tallest standing Buddha."
|
 
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
© Copyright 1997-2005 Dave Winer. The picture at the top of the page may change from time to time. Previous graphics are archived. Previous/Next |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
