The main issue that Comanche wants to address was the lack of appropriate management tools for popular internet software. The Apache web server and derivatives runs on more than 60% of all internet servers (acording to Netcraft). Sendmail runs in approximately 75% of all mail servers on the internet ( Sendmail website). ( Bind has a virtual monopoly for internet DNS servers. Big organizations running SMB networks (windows file and printer services protocol) often turn to a Unix Operating System running Samba for their mission critical file servers..
These programs are free. Their source code is available for inspection and customization. However, although they are often technically superior to their commercial counterparts, they usually lack good management software. This steep learning curve often hinders their adoption both by the casual user and large corporations who want to keep down their administrative costs.
The purpose of this project is to implement a management system, code named Comanche, geared toward improving the usability and widespread adoption of Internet related Open Source software.
Design goals:
After downloading, compiling and using many configuration programs and management frameworks, it was felt that there was room for improvement, and thus the idea of writing Comanche was born. Some of the key points that motivated that decision follow. To describe them, some thoughts are borrowed from the author of Perl, Larry Wall.
Comanche, as any other open source project can benefit greatly if other people were able to contribute to it. The idea is to develop a framework that encourages other programmers to contribute. Successful open source projects have a modular architecture. To become productive, a developer only has to deal with the module API and a few concepts of the overall architecture. The learning curve is much higher for one piece monolithic programs.
Existing frameworks usually aim to be comprehensive solutions, providing special functions for registring and accessing configuration files, starting/stopping programs, etc. This increases the amount of knowledge required to build even the simplest of the modules. One of the goals of Comanche is to make it easy to develop plug-ins. The API should be kept simple. A developer should be able to write a simple module for Comanche in a very short amount of time, without precluding the development of more complex modules.
Some of the existing frameworks restrict the developer to the use of only certain extension languages, like C++ or Java. The design of the framework should not restrict the developer to the use of only certain languages.
Configuring complex programs can be a daunting task. Hard-coded interfaces make painful to maintain the program when new versions of the application are released and that requires changes to the syntax of directives, redesign of existing dialogs or creation of new ones. Usually all this requires changing the source code and recompiling with existing frameworks. It will be desirable to clearly separate the interface and directive description from the configurated engine itself, so interfaces can be generated dynamically.
If this separation of content from presentation can be achieved, then it would be possible to maintain different versions of the interface. New users would be presented with the minimum set of information required to configure the program, while experts would be presented with an advanced view, that exposes the more obscure details.
The design of the program should be kept as simple as possible while covering the most common cases and uses. This may involve some functionality tradeoff.
In this case it is believed that it will be a better, faster, rounder wheel.
Now that it has been stated what the ideal configuration framework, it should be analyzed which problem it should/would solve for different target groups:
It should help them set up and manage popular open source applications like Apache and Samba. It should make the process easy by hiding the complexity and guiding them through the different options using wizards. When they feel confident, they should be able to switch to expert mode and be able to configure the more obscure parameters.
Usually experienced administrators set up an infrastructure to automate repetitive tasks (like adding users, creating mail aliases, etc.). This is usually accomplished using Perl or shell scripts. This kind of infrastructure is often poorly documented and the know-how is difficult to transmit. Comanche can make it really easy to create administration scripts and provide a graphical interface to them that can be then used by junior administrators.
It should help them providing a simple API, so they can concentrate on their original purpose: configure the application. The framework should take care of presenting an unified interface and interacting with the user.