SpaceClaim’s Versioned API
Today we released new installers of our SpaceClaim add-ins which support SpaceClaim 2010. SpaceClaim released 2010 just a couple of days ago and in fact our add-ins were ready the same day. Just that we needed to make some very minor changes and test them thoroughly with the new version.
Usually partners get access to the beta versions so that we can test our add-ins with it. I am not sure exactly why, but SpaceClaim didn’t do that this time. At least not with me. But it didn’t make much of a difference. That’s because they use a versioned API, which is something that probably needs a little explanation. Here is what the SpaceClaim installation folder looks like.
The highlighted folders contain one DLL each and some documentation on how to use them. The DLL file name is the same as the name of the folder and is basically a snapshot of the API that is frozen for life. This means that no changes will be made to the DLL in a future version of SpaceClaim. All SpaceClaim add-ins need to talk to one of these API DLL’s. Which one is entirely up to the add-in developer. For example, all our add-ins talk to the SpaceClaim.API.V4.dll. Even the updated ones that we released today. Why? Because they do not use any new features added to the later versions of the API DLL’s. So there is really no benefit in linking our add-ins to V7 of the API. If we did then people using earlier versions of SpaceClaim would not be able to load our add-ins since their version would not have V7 of the API.
There are a number of advantages to having a versioned API. For starters, the add-ins will work with all future versions of SpaceClaim. At least technically they should. But its a good idea to test anyways. Secondly, as a developer you can be sure that your add-ins will work in the same way in a future version of SpaceClaim. For instance, suppose the API was not versioned and there was just one API DLL which got updated with every new version or service pack of SpaceClaim, the add-in would behave differently if it called a function in the DLL whose functionality had changed. Lets suppose I used a function in the API that wrote out a R12 DXF file which was to be used as an input to some other external operation. Now suppose five years hence, for some reason, SpaceClaim drops support for R12 DXF and instead writes DXF files from AutoCAD 2000 onwards only. My add-in may continue to load into SpaceClaim but will not be able to do the job because it relied on an API function that can no longer write a R12 DXF file. There are ways of preventing this by creating different versions of the functions in the same DLL. But that is really under the control of the CAD vendor and not the add-in developer. For this reason it is quite common to read warning messages like the following in the API documentation: “This function is deprecated and may not be available in a future version. It is strongly advised to use this other function instead.”
Developing SpaceClaim add-ins is quite simple and straightforward. You can join their partner program. But I don’t think that’s a requirement since the API is open and included with the product itself. SYCODE is a SpaceClaim Technology Partner and I have personally worked with SpaceClaim since V1 of the API. Actually I find it kind of funny. Years ago, when the company started out, I was working very closely with their technical team developing our add-ins while at the same time bitching about their business model on this blog. But then I do that with just about all the CAD vendors. I get the feeling that their technical and marketing teams don’t discuss work with each other a lot. 😉