Daniel Berlinger wrote OK. But I think what Dave just did was open up the path for extensibility.

Absolutely.  Dave blasted a rather large hole through a small number of APIs.  And did it in exactly the right way - one that matches parameters by name.  And tells implementors to ignore what they don't understand.  Bravo.

There have been some discussions about style (how much struct is enough? One implmentation uses a single param -- a struct -- that contains everything else, the method call, the params etc.

I personally don't believe that there is one right style.  My preferred approach would be to design a clean XML message.  One that would be easy for multiple vendors to map to the styles that make the most sense to their users.  Truth be told, for interop purposes, I don't care how you chose to present an interface to your users, I only care what you chose to send across the wire.

I don't understand how you can say "orchestrating the upgrade of all clients and servers across the internet each time this occurs" will be eliminated. In your example, you add a param to a call, and as is the general rule, servers ignore anything they don't understand. So if I add the param to my client it's either ignored by the server or the server gets an upgrade. How is this real world different?

They don't have to all have to be changed at once.

Let me repeat.  Dave did exactly the right thing.  As he undisputably has done countless times before and will continue to do for the forseeable future.  However, at some point there will be a collective "AHA!".  And I plan to be there when that occurs.

  3:12:21 PM    

Daniel Berlinger wrote [on a server where the permalinks appear to be broken]

Thanks Sam. Much appreciated.

You are most welcome!

Here's what I took away from this document and recent discussion. SOAP can be simple.

Exactly.

There are more and longer incantations to remain aware of, although at the simplest level they're noted in the BDG.

The biggest things not mentioned in the BDG are hrefs and headers.

Folks in the SOAP world have moved past the listed incantations in the BDG with support for other types (which may be listed elsewhere, I haven't looked.)

The complete set of types that the SOAPBuilders has added to the list of we track interoperability on are: hexBinary, decimal, and boolean.

Next question. What does SOAP buy me as the smallest of developers? I understand that it might be necessary if I want to hook up to the Big Guys. What else? (and thanks again.)]

The simple ability to Cope with Change.  As an example, right now there is no blogging API with critical mass which supports titles.  We can continue the process of blasting holes, re-establishing consensus, and orchestrating the upgrade of all clients and servers across the internet each time this occurs, or we can chose to build extensibility into the protocol itself.

A parting thought... take a close look at the BDG fault example.

  8:24:07 AM