Hi I am currently working on an overhaul of the configuration file system for the MacOS X port of Asterisk, primarily in order to integrate better into the OSX environment. Yet, what I am embarking on would be beneficial to other platforms as well and some folks in the IRC channel suggested I should post to this list describing what I am up to and at the same time invite comments.
In a nutshell, the overhaul involves the following ... Consolidation and reorganistation of configuration files: - static data will consolidated into a single file - static and dynamic data will be separated - data of core and plug-ins will be separated - storage method of dynamic data will be configurable New default format for configuration files to allow nesting of categories: - NeXT plain text property list format will be default on platforms other than Darwin/OSX - XML property list format will be default on Darwin/OSX - Use of open sourced CFLite library hides actual formatting (XML, plaintext, binary) Legacy format support: - Option to autogenerate legacy INI formatted shadow files (read-only) - Conversion utility to import and export INI formatted legacy files And in more detail ... * Consolidation and reorganisation of configuration files: a) all configuration data that is of static nature, ie. justifies or mandates a reload, will be consolidated into a single configuration file, that is to say ... asterisk.conf, respectively openpbx.conf logger.conf manager.conf modules.conf extconfig.conf will all be rolled into a single configuration file called asterisk.plist, respectively openpbx.plist and its location on Darwin/OSX will be /Library/Preferences, while it will be located in /etc on other platforms. In addition, a symbolic link will be placed in the configuration directory, by default /etc/asterisk, repectively /etc/openpbx. If the master config file/plist is not present at startup, the core's configuration subsystem will create it from factory defaults. b) configuration data of dynamic nature will be stored separately from configuration data of static nature, that is to say the dialplan should continue to be a separate file or database. The location and name of the dialplan as well as its format will be configurable and stored as part of the core's static configuration. c) configuration data of plug-in modules will be stored separately from configuration data of the core and by default each module will have its own configuration file. Optionally, modules may store their configuration data in a database shared amongst multiple modules. The location of a modules configuration data and format will be configurable and stored as part of the core's static configuration. * New default format for configuration files ... an example of a consolidated master config file in plaintext plist format is available at http://www.sunrise-tel.com/misc/asterisk.plist.txt an example of a master config file in XML plist format is available at http://www.sunrise-tel.com/misc/asterisk.plist a screenshot of Property List Editor with an example master config file open can be seen at http://www.sunrise-tel.com/screenshots/Asterisk.plist.2.png * Legacy format support ... If the option "INIShadowConfigs" is set to "yes", the core's configuration subsystem will dump all configuration data into INI legacy formatted configuration files for documentation purposes whenever a reload or restart is invoked. A separate conversion utility to convert between legacy INI format and plist format (preferably plaintext) will be made available to allow import and export of legacy config files. * Outlook on how to deal with the dialplan ... I have not yet put much thought into how to deal with the dialplan at this stage. My intention is to leave it mostly the way it is now for the time being. However, I have done some experimentation with how the existing dialplan syntax could be represented using plaintext plists. I have also experimented with some ideas how to define patterns for matching numbers/extentions. some of this can be seen in a work in progress snippet of imaginary dialplan ... http://www.sunrise-tel.com/misc/dialplan.txt I am not exactly happy with the way line numbers are represented in there, however, I like the idea to keep an overall framework of dialplan while at the same time allowing the actual script components to be configurable and thereby in different languages. COMMENTS Any constructive criticism or comments on this are welcome. However, any comments with the tenor "you shouldn't be doing this" will be IGNORED as this work will be carried out for OSX integration regardless of whether or not the community wants to adopt it for other platforms. In other words, I am happy to discuss details, but I won't change my mind that an overhaul along the lines outlined here is necessary. regards benjk ___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
