On Wed, Mar 19, 2008 at 08:24:12AM -0800, Gary Winiger wrote: > > Nicolas Williams wrote: > > > But one thing is clear: the architectural direction for Solaris is and > > > long has been to move away from configuration files whose admin > > > interface is $EDITOR. > > > > > > > > Just curious. What is/was the reasoning/logic behind this change? > > What was seen as being so valuable that would overcome the negatives of > > being so different from other Unix platforms? > > Separation of duties and accountability to name two. Data > validation and format could be two more.
Allow me to add some more: - Simpler upgrades. Rather than have pkg scripts that edit config files to upgrade them to the latest format/whatever, we can instead have code in the services that notices old property values and fixes those. Less brittle upgrade scripting -> better for me and better for you. - To expand on Gary's data/format validation point: storing config data (e.g., 'files' name service backend files, large IPsec policies, ...) in databases allows us to optimize for common tasks (listing, searching, ...) when dealing with large datasets. - And to expand on the previous point, it's easier to change schemas too that way. - The alternative is to alway suck in textual config data if you need it to be in a database, and you have to detect changes to the text file and suck all of it in when it changes, with no idea if the delta is tiny or huge. Plus format evolution is highly constrained by the original format, whereas with an adm command to make small and large changes alike, we can have multiple exchange formats if need be. A good example of a lot of these points is idmapd(1M). It supports multiple data exchange formats, it uses a SQLite2 DB, we've never needed pkg upgrade scripts even though we've had to change the underlying schema, and all the upgrade logic we've ever needed is in SQL anyways and it's easy to add new upgrade logic. Nico --
