Dave's SOAP Journal, part 2

Tue, Mar 27, 2001; by Dave Winer.

Previous installments 

9/25/99: Dave's History of SOAP.

3/24/01: Dave's SOAP Journal, part 1.

An interesting couple of days? 

I'm going to keep this document open for a couple of days. I have an interesting project to do.

I want to write, with Jake's help, and anyone else who wants to get in the loop, a four-screen spec for SOAP interop.

The clock is ticking, every day delayed is another day wasted before Microsoft ships their software and changes the rules. I want to have SOAP interop before Microsoft ships.

Parallel track 

At the same time, Jake will keep posting to the soapbuilders list and will document his work in his journal. To be clear, Jake works for UserLand, and therefore, works for me. We're pursuing both threads and trying to accomodate the rules of the list, as we understand them.

Transparency 

Talking with Paul Andrews the other day I asked if this stuff was going over his head. I'm trying to make it understandable to people with non-technical backgrounds. We have a seat at one of the most interesting tables in 2001, perhaps the most interesting table. I want my experiences to be transparent, I want all the glitches, near-flames and full-flames to be out in the open so we can resolve our differences.

Others are not seeing it the same way, and are working in private, and in doing so disempowering people they don't include. I give you my word that my role in all discussions and my thoughts and pushback will be visible. I can't stop and answer all questions, there isn't enough time, but later when people ask how this happened, you'll be able to see what I did, even if you can't see what others did.

This method has worked well in every stage of SOAP, the only times we got in trouble was when the decisions were made behind closed doors. I believe you can see that result in the SOAP 1.1 spec which is a marvel of compromise and confusion. Our job is to clear that up so we can all move forward compatibly. I want a spec that's a marvel of clarity and ease-of-implementation. I want the barrier to entry for SOAP to be as low as possible, so as not to favor Microsoft, which has 45,000 employees, and many thousands of programmers.

Two choices 

I see two choices. The first is to document the common elements of various SOAP implementations we've been working to interop with. The second choice is to punt on that and define a SOAP envelope for XML-RPC messages.

The advantage of the first approach is that it's kind to SOAP and won't jar the existing SOAP community, which is large and confused.

The advantage of the second is that it opens the gates for all the XML-RPC implementors to participate in the SOAP world, with a minimum investment. I believe our energy is very much needed in the SOAP world.

Microsoft 

Wednesday morning, 7AM.

As a Mac developer, I could admire Microsoft from a distance, even though they played the BigCo game in Apple's space at the expense of the SmallCo's (Apple did it too). I admired Microsoft because they were smarter than Apple about technology. But as I've gotten closer to Microsoft, the same thing has happened with me that has happened with virtually everyone else that's tried to work with them.

I've come to see them primarily as a bully that uses its advantage at every step, whether they need to or not, to achieve their goals, and they play on peoples' ignorance and willingness to believe that somehow they're special, that Microsoft respects them even as they dis the others. Even in an area that's probably of minor significance to them, they don't ever show restraint, repeated calls for them to back off and let people work openly are ignored. There's lots of offlist activity, and when it emerges Microsoft is always there. "Oh we're just tool vendors," they like to say then. Uh huh. A tool vendor with 45,000 employees, the dominant desktop operating system, and $27 billion in cash.

My experience now matches the stories I've heard from others, they must have a playbook for dealing with outsiders, and they stick to it. I don't believe they can participate in an open development process without spoiling it.

I know many people are nodding as they read this, but I had to do the experiment, I'm that kind of guy, I had to get the data.

Survey results 

Yesterday I ran a survey asking Scripting News readers and members of the soapbuilders and xml-rpc lists what they think the outcome of the SOAP interop work will be.

31 percent chose "SOAP will be a balkanized 'standard' with major (or minor) differences between the implementations. There will be a group centered around Java, one around Microsoft, one around independent developers, or some combination thereof. Interop across the 'clubs' will be very problematic, with all groups blaming the others for the lack of interop." It was the highest-ranked choice.

19 percent chose "Works with Microsoft."

13 percent chose "A simple subset of SOAP will be indentified and documented, much like XML-RPC, but using SOAP envelopes."

My choice 

I voted with the 13 percent and that's where I'm putting my bet. I'll do some work over the next two days to draft A Busy Developer's Guide to SOAP 1.1. If it works, you should be able to adapt an XML-RPC implementation to be a SOAP 1.1 implementation in two sessions, one to get the basic code written, and one to test and debug against a validator.

It's a bet-hedge against the most popular choice. If it's going to be a balkanized standard, I want to be sure that my software is in at least one of the major groups. It would be disastrous for us if we had to go with the "Works With Microsoft" choice. That's a losing proposition. At some point the hoops will get too numerous and we'll have to bow out. Better not to waste any effort on that choice, it's totally unworkable.

Examples 

Last night I asked Jake to prepare examples for A Busy Developer's Guide to SOAP 1.1 that, like the XML-RPC spec, shows a developer what a request-response looks like. This will be the core around which the spec is developed. The examples are here.

The first draft is ready 

At first I thought I'd do the writing and then pass it by Jake, but he knows so much more than I do about the twisty maze of SOAP interop, and how big it is, and what the other developers are doing. So we wrote the spec together, me writing and Jake correcting and explaining. It was a great process. We've never worked so closely together, in real-time. Jake is always proving smarter than I thought he was (and I always thought he was smart).

It took about six hours to get the spec done, but in those six hours I think we accomplished more than the soapbuilder process would accomplish in six weeks.

At about 2PM we passed a pointer over to Simon Fell to review. He's also been involved in the interop process on a daily basis, and has been working closely with Jake.

I am now confident that I understand all I need to know to get SOAP interop at least among the developers who want interop, more than they want to be friends with Microsoft. I would love to see Microsoft say they're going to support the Busy Developer's Guide, and then we're done, and we can get back to adding features and fixing bugs (and adding bugs) to our software, which is how we earn our paychecks. I'm sure this is something a Microsoft person could understand.