Taking a look at "launchd"
After reading through some feature lists of Mac OS X.IV (10.4 for those of you who have forgotten your Roman Numerals) and now being a Mac user (see mini order below) and reading some of the typical blather from Slashdot about why they conceive of 10.4 in a good or bad way, I thought I'd throw my 2 cents in. Particularlly I wanted to talk about Launchd, the new system "init" process that manages launching programs and their dependencies in 10.4. (Is it just me or is it syntatically odd to put a decimal number at the end of a sentence?)
On a standard Unix, or even Windows, computer there are always text based configuration files for some particular service or another. Each of these files supplies information to a program to be used to configure the state of the software so that it may function properly. Without them you quickly find that you can't get information without having some first. This isn't necessarily a true paradox or contradiction it's just an dependency. But simply put, there is always some bit of information you need to know so that you can then find out more bits of information. This is, as I will refer to it as, the Big Picture Problem of Configuration.
In the early times, every one agreed that this was an issue that needed to be addressed. Everyone agreed that there should be some way to have this information written down somewhere in the persistent memory of the software so that it could be known. And every one set off solving this problem in their own way, which was fine because their problems were not inter-related yet. Years pass. Services mature and have more features. Computers run more services. Services become ever more complex. Configuration languages evolve to match this complexity and become whole areas of study unto themselves. Now we have a meta-problem. That is, we have lots and lots of solutions to the same problem; each service reimplements a text file parser with similar levels of complexity, similar features and with similar requirements. So why don't we have one large-scale well thought out solution? Obviously we have "historic reasons", which is the same as saying "don't fix it if it ain't broke". Obviously we have a culture of DIY, where we don't like having a standard imposed on us. And lastly we have a mentality to "keep it simple, stupid", which means we don't want seemingly superfluous complexity in our solution.
Launchd was created to solve these meta-problems. The meta-problem is not entirely accurately described as a congolmeration of smaller problems, but more of a problem about configuration problems. Since we have all these disparate solutions and so many services solving the same problem in roughly the same way but with unqiue deviations, there's just a great deal to learn about configuration. Granted, even if or when launchd style solutions do prevail, each service will still have it's own type of data, just not it's own way of storing it. By using XML launchd can provides a uniformly parsable configuration file for every service that is self-validating. This means it provides enough information within itself to tell the parser if there has been an error in that file; not only a syntatic error, but some forms of sematic errors. It still can't detect logical errors (humans can't do this either, reliabely at least). You may be for or against this. Most of the "debate" about using XML comes down to either pro) it's understandable by humans and machines or con) it's barely understandable by humans and slow to parse by machines. You may note that the con is subjective, while the pro is factually stated; objective. How hard or easy it is for you to read XML is based solely on your own experience with it. I tend to like it because I've used it. Your Mileage May Vary. In the end, launchd's conceptual purpose of consolidating the configuration landscape of the computer is a useful meta-problem to solve, regardless of the language or syntax to do it with. XML simply provided lots of benifits that other less developed methods couldn't provide.
