Cook Computing

Coded an XML-RPC interop test matrix web page this evening. Two of the current failures are because the noInParams method has only just been added to the test suite and the servers have not been updated. I would have preferred to flag these failures in a different color but each implementation returns a different fault code for this error condition. It would be helpful if some standard fault codes could be agreed upon by the various XML-RPC implementors.

Released version 0.2.0 of XML-RPC.Net. I was hoping to complete the changes to allow calls to be made asynchronously but these will have to wait a few days. This release still needs more testing which I've been putting off until all the async changes are finished.

0.2.0 passes the interop tests when called from Jake Savin's Frontier test client.

On further reading of the W3C docs I discovered that a schema does not define the root element of a document described by the schema. Therefore it is ok for a single schema document to contain definitions for both methodCall and methodResponse. I merged the two schemas into a single document. This solves the problem with the common types.

I've also started annotating the document.

Just updated the schemas: methodCall.xsd and methodResponse.xsd.

Andreas Bolka pointed out that the params element is not necessary for method calls with no parameters (depending on how you interpret the XML-RPC spec).

I also modifed the valueType definition to partially handle the case when the type sub-element is not used. The mixed="true" attribute and the minOccurs="0" for the xsd:choice allows:

<value>some text</value>

and:

<value><string>some text</string></value>

but also allows:

<value>erroneous text<string>some text</string></value>

Unfortunately I'm pretty sure this is as close as you can get with XML Schema.

I'm currently learning XML Schema. As an exercise I'm working on schema documents for XML-RPC request and response. This work in progress can be found at: methodCall.xsd and methodResponse.xsd.

I still have several refinements to make and some outstanding issues as to what the XML-RPC spec means in places. Outstanding work includes:

- definitions for some common types should be factored into a separate schema document (my schema editor doesn't support this)

- value types not specified in detail

- I haven't worked out how to represent the case for valueType where a default type of string is assumed:

    <value>some text</value>

which can co-exist with the non-default representation of string, i4, etc, for example:

    <value><string>some text</string></value>

Any feedback on what I have done so far would be very welcome.

Big problem on the client-side change. The new base class for proxies - XmlRpcClientProtocol - is derived from a .NET class - ClientProtocol. This works fine until you try to access an invalid URL when calling ClientProtocol's Send method. An exception is dumped to the console and the call to Send never returns. I guess this will have been fixed in beta 2 but for now it means I have to code my own version of ClientProtocol. Which is frustrating because ClientProtocol provides a lot of functionality.

Currently working on a major revision of the client-side of XML-RPC.Net. I'm implementing a class called XmlRpcClientProtocol which is modelled on the .NET SoapClientProtocol and HttpClientProtocol classes. As well as providing HTTP features such as authentication, proxy support and timeout, this class will enable clients to make XML-RPC calls asynchronously.

Started using Blogger. Old entries posted below.

Wednesday 4th April 2001

PM Fixed Content-Type header as described below. Working on some sample code for inclusion in Eric Kidd's excellent XML-RPC HOWTO.

AM Andreas Bolka emailed me that XML-RPC.Net is returning the following incorrect Content-Type header:

charset=iso-8859-1

I'll update the public Services hosted at Secure Domains this evening and put the fix in the next release.

Thursday 29th March 2001

PM Eric Kidd has run his C++ Class Generator (running on Linux) against the XML-RPC Introspection API exposed by the .NET ValidationService sample (header, source, and automatically generated documentation). Who needs WSDL?

Wednesday 28th March 2001

PM Released v0.1.3 of XML-RPC.Net. Includes support for nested arrays (jagged and multi-dimensional) and the Introspection API. The XmlRpcMethod attribute can now be marked as Hidden which means that the method does not appear on the auto generated doc page or in responses from the Introspection API.

In addition to learning a lot about how arrays are supported in the .NET I fixed a few bugs in this release and started to improve error handling and reporting. I intend to implement some substantial test code before the next release which will be 0.2.0 (the XML-RPC validation suite is only a starting point).

I also plan to start coding some Services and clients in VB.Net to prove that XML-RPC.Net is fully CLS compliant (even though the compiler says so already.....).

Thursday 22th March 2001

AM Reported the Meerket problem to the oreillynet.rss forum - looks like one or more of the parameters in the getItems call in the testmeerkat sample is now invalid and the Meerkat server is incorrectly emitting some diagnostic output into the XML body of the Fault Response.

Decided to disallow .NET class methods marked with the XmlRpcMethod attribute from returning void. XML-RPC does not specify a way of returning a response from a void method.

Started to implement the Introspection API and realised that support for multi-dimensional arrays and arrays of arrays is currently missing from XML-RPC.Net, for example as in the parameter and return value of this method

  [XmlRpcMethod] 
  public int[][] getArrayOfArrays(int[,] param1) 
  {
    ....
  }

Tuesday 20th March 2001

PM Two problems this evening running 0.1.2. First, I've been seeing intermittent networking errors on the client side, particularly when running via a proxy server. But everything works fine on the LAN. I've had various problems with System.Net over the last few months which were reported to the relevant team at Microsoft so I won't have great faith in this area of the .NET libraries until beta 2. Second, when running the testmeerkat sample client I'm getting back invalid XML from the Meerkat server when calling the getItems method.

Suggested on the XML-RPC mailing list that the spec be extended to cover methods returning a response with an empty <params> structure. This would be useful to map .NET class methods which return void onto an XML-RPC response.

AM Updated the distribution to 0.1.2. In addition to the features mentioned below this version now makes available the HttpContextobject when a request is being processed. This allows stateful coding at the Application and Session level and various other things).

The ValidationService has also been enhanced to include a couple of methods to test the handling of parameterless requests and methods which do not return a value.

Sunday 18th March 2001

v0.1.2 of XML-RPC.Net validates using the validator at Userland. The ValidationService demo has been updated and was used for the alidation.

This version includes support for dateTime, base64, and a hashtable-based class XmlRpcStruct for handling variable-size structs. I haven't had time to update the distribution today (I've been implementing the handling of parameterless methods and methods returning void) so that will have to wait for a couple of days.

Friday 16th March 2001

Added new demo Service - ValidationService. This is a partial implementation of a server which can run the XML-RPC validation suite. The missing methods require variable-size structs which XML-RPC.Net does not support yet (planned for this weekend coming).

I realised that the automatically generated doc pages should display the XML-RPC parameter and return types - not the .NET types (but maybe those also).

Wednesday 14th March 2001

Name change to XML-RPC.Net. Release updated to 0.1.1 to reflect this. New samples also added to distribution.

Tuesday 13th March 2001

I currently have two publicly accessible XML-RPC Services running under .NET: MathService and TimeService. They're both XML-RPC versions of Web Service examples in MSDN magazine. MathService has 4 methods and TimeService has 1 method - look at the URLs in your browser for the automatically generated doc pages. I'll add them to the dotXmlRpc distribution tomorrow.

Thanks to Secure Domains for providing the hosting.

Sunday 11th March 2001

Initial release of dotXmlRpc. Although this is still very much prototype quality code, the client code does work sufficiently well to make calls to the betty and Meerkat servers which are publicly available on the Internet. I'll soon be adding some sample XML-RPC Services.