Sunday, March 26, 2006
Over the past year or so, my group's applications have started using XML instead of the older, poorly documented, ad-hoc data formats we used in the past. In the client application, we are using XML for these purposes:
- Application configuration
- Network configuration
- Screen layout
- Communications with the server
We have these four uses of XML, so of course, we have four different XML parsers linked in to our application. One is Xerces, and the others are home-grown. The guy who used Xerces put his own "easy-to-use" wrapper layer around it, so you could say that we really have five XML APIs within our application.
As you can probably guess, the three home-grown parsers were written by three different people. At least two of them gave their header file the name "xml.h", so there was a lot of fun trying to get everything to compile when multiple parsers were integrated. We also had two "xml.lib" libraries to contend with.
At some point, we'd like to have just one XML parser. But that would take a week or so, and right now the schedule doesn't allow us to spend a person-week on something that doesn't help us make the deadline. So we'll fix it later. (Yeah, right.)
It's times like this that I really wish we were writing our app in Python, Ruby, C#, or some other language that has XML support built-in to the standard libraries (or which has a de-facto standard implementation). C++ was created before XML, so there is no standard way to handle XML. C++ programmers who need to support XML take a look at Xerces and other off-the-shelf libraries, but then most of them decide it would be easier to roll their own than to figure out the complex APIs the libraries provide.
What really bugs me is that none of these uses of XML are making things any better. They bloat the app (the Xerces DLL alone is bigger than the rest of our application), and they make it more difficult to build and to debug. But I guess it's what the cool kids are doing these days.