Woody, could you elaborate on “ . . . and very powerful from an object oriented point of view.”? Thx.

Though it is true that .NET has a great deal of facility in processing XML, that's not the case with VB6.
I do use .INI files for my VB6 web app suite though. I wanted to be able to make modifications to configuration at the drop of a hat, and without having to stop anything that was running. So I read the .INI info at the beginning of every Request.

First of all, the VB6 xml capabilities are very strong, in my opinion. All the functionality you need is available in the MSXML components. I've used it for years and its worked well for me.

In many ways there is nothing wrong with INI files, and in some ways they are similar in purpose and use to XML files. However, typically you cannot easily represent a deeply nested model with INI files - they provide a grouping mechanism, and a key:value mechanism, and that is about it.

So... I see XML configuration as being able to contain an object graph that can be nested as deeply as you like, and makes it easy to relate attributes as well as values at any level. From an object oriented point of view you can traverse the tree of the XML and reconstruct or "rehydrate" just about any set of objects you have need for. In .NET there are mechanisms provided by the framework for dealing with this - but there is nothing complex or magical about them, and the same pattern can easily be followed in VB6.

In a way, this type of configuration can be thought of as a mini-language that can drive an object factory. This sort of thing allows for you to configure an application so as it begins work on something it can flesh out the configured objects via an abstract factory pattern. This is great for things like strategy pattern where you create and use the objects that are configured for some purpose, and never have to use conditional logic to determine what the configuration is.

Anyway - that is just a quick start on the idea of how powerful this sort of configuration can be. Obviously, you could create a similar model using traditional INI files, with KEYs in higher groups will have groups of their own with additional information, and so on, but this becomes very laborious and hard for humans to view, whereas XML was invented for this sort of thing. The registry can also store hierarchical data, but again - its not nearly as easy to work with as XML.

Additionally, this sort of data can also be stored in a database, and sometimes that is a much better place to put it (as opposed to as files somewhere). In this scenario the data could be stored in the same manner as other application related configuration. On the other hand, the data could be stored as XML with the db merely providing a place for the storage rather than the stucture. To me, this is also a very powerful model. The advantage of XML over the traditional Relational db model is that the XML is easily changed and extended on the fly with no change to the database tables. There are a number of considerations, but as far as I am concerned this works well if you work out all the details.

At the same time, XML can provide very simple configuration information in a much more readable and flexible form than the INI or registry models. You can read the XML into a document, and then search it and work with it in a more or less natural manner.

I hope that helps.

Woody Z http://www.learntoprogramnow.com