Cook Computing

Sql Data Types and Missing Mapping Action

January 13, 2003 Written by Charles Cook

Following on from the previous entry about handling missing struct members in XML-RPC.NET, I coded a prototype using a new XmlRpcMissingMappingAttribute class yesterday. However I'm still not all that pleased with this solution. It gets a bit messy when you want to define an interface representing an XML-RPC end-point where the interface is to be used by both the server and client.

Say a method on the server returns a struct containing two integer members called Required and Optional. You could write a struct like this in C# to represent the XML-RPC struct:

struct Sample
  int Required;
  int Optional;

When serializing an instance of this struct in a response, if the value of Optional is zero the server cannot determine whether to include a corresponding member in the XML-RPC struct, i.e. a similar problem to that faced by the client as described in the earlier entry.

An alternative approach is to use data types which can be null, for example like Java's Integer, Boolean, etc, classes. I found a couple of archived list messages from other developers looking for something similar: Steve Ballard and Jeroen Frijters (Jeroen is doing some very interesting work on a Java VM for .NET).

Jeroen's message mentions SqlInt32. This and its associated types are value types which have an IsNull property (different to the Java types mentioned above which are reference types). So, the missing mapping problem could be solved by using these types where a member in an XML-RPC struct is optional. The client or server application code could then call IsNull on each of these member to determine whether they were present in the XML-RPC struct.

Going down this route I'd probably provide specific types for XML-RPC.NET, for example XmlRpcInt32, because using types whose name is prefixed with "Sql" does jar a bit. The Mono project has implemented the SQL types so I can use their code as the basis for the new XML-RPC types.

I just need to think through how to handle structs. I have to say that these attempts to support XML-RPC in a statically typed languge does make me look longingly at more dynamically typed languages. This post from Pinku Surana (via Managed Space) was interesting reading about a major deficiency of the CLR for supporting dynamically typed languages; and slightly depressing from a language diversity point of view:

As it stands now, dynamically typed languages run pathetically slow on .NET and JVM. The question is whether C#/Java is so horrible that one would willingly take a significant performance hit to write Scheme/Lisp/Smalltalk? I'm getting used to Java/C#, so I would answer no.