intertwingly

Dave wonders how much extensibitity?

How much is the right amount? You end up chasing your tail. If an API is perfectly extensible then it says nothing about interop.

What we are discussing is alternate ways of expressing the concept:  The server must ignore all elements that it doesn't understand.   One can achive this in an interoperable way.

Something has to be nailed down. Always at the cost of extensibility.

What should be nailed down is the bits and bytes we exchange over the wire.  If I want to pass a title or a mood across the wire, should I add SOAP parameters:

<title>Bing!</title>
<mood>happy</mood>

Or XML-RPC struct members:

<member>
  <name>title</name>
  <value>Bing!</value>
</member>
<member>
  <name>mood</name>
  <value>happy</value>
</member>

Both are equally as extensible.

Imho, interop and extensibility are two opposing forces, like time and space.

Nope.  Interop is about Dealing with Diversity.  Extensibility is about Coping with Change.  One can do both.

One more example, and then a conclusion. The developers of Conversant boast that they've gone so far towards extensibility that their interface is all structs, even the name of the procedure that's being called is encoded in a struct so presumably if the way of expressing the name of the procedure requires extension there will be no breakage. But have they actually done anything other than replicate XML-RPC?

What they have actually done is re-invent named parameter asssociation.  Something that is built into SOAP.

Now the conclusion. We have to agree on something, for better or worse, in order to move forward.

We should agree on the bits and bytes sent across the wire.

You can't keep all the options open for all time.

Example: keeping the option open for both XML-RPC and SOAP, and thereby coding to the least common denominator, requiring designers to make the choice between brittle [positional parameter] interfaces and more complex [structs as parameter] interfaces.  Eliminating the choice to make simple and extensible [named parameter] interfaces.

This means there will be corner-turns. So far the Weblog API world has been very collegial and has produced real results at a very low cost. I believe we will be able to move forward, and the protocols and formats will evolve in a market-driven way, and when the corners are turned we will look to the tool developers to insulate users from the bumps.

A tool to go through your scripts remove all the structs and convert them to parameters?  Yea, sure.

I'm reminded of something Joel on Software said:

My friend, you can put wheels on your mama but that doesn't make her a bus, and if you think you can refactor your wrongly-implemented file-copy function to make it preemptive rather than threaded as quickly as I could write that sentence, you're in deep denial.

and

It's one of those weird forms of laziness where you end up doing more work than you would have done otherwise. I'm too lazy to design the feature on paper first, so I just write some code, and then it's not right, so I have to fix it, and I spend more time than I would have otherwise.

We have a real opportunity here.  There is an API that is in popular use which clearly isn't as extensible as it needs to be.  We can apply bandaids and put off the corner turn for another day, or simply say the blogging API is what it is.  Now here's another API which is as easy to implement and is more extensible.