I don't get it

(sorry for my english)

All is on project page...

To specify structure and default values of all module settings in one place by using "hook_get_settings()".
But not on every "variable_get()". So if you will decide to change default value of your setting, all you need is to change it in the "hook_get_settings()", not on every "variable_get()" call.
You have also ability to override default value by specifing one directly in "settings_get()" call.

Automatic consistency check, so you will only use settings that you defined.

Delete all settings in my_module_uninstall() by calling settings_delete_all('my_module'). So if you add or remove settings between different module versions you don't need to control it deletion manually, they will be deleted automatically by "settings_delete_all" call.

And the main feature:
Automatic specify default values ('#default_value') for admin settings form by using "settings_prepare_settings_form('my_module', $form)".
For use example see bottom of http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/bittorrent/...

I hope I answered on your question.

P.S. Also you can see the code itself, each function has nice comment.

Here's the db call to clear all variables associated with the module. This is what we use for boost inside boost_uninstall().

  db_query("DELETE FROM {variable} WHERE name LIKE '%s_%%'", 'boost');

What if someone in other module (not in "boost") will use variable like "boost_*"?
You will delete it.
I know that vars have to be prefixed with module name, but this is not controlled by core, an every one could to od this.
Also if such var will be used not in module, but in theme named "boost", afaik theme can share names with modules.
This module also has these disadvantages, but I think that I move in right direction.

I could get all settings by doing something like this (untested code below).

  $result = db_query("SELECT * {variable} WHERE name LIKE '%s_%%'", 'boost');
  while ($result = db_fetch_array($result)) {
    //get variable names & settings
  }

You could get settings, but not their default values unfortunatelly.

The above 2 tricks should be placed in the forms api handbook, so developers can write cleaner code in their own projects.

I think, that they shouldn't, because, they use table directly and if variable table structure will change everyone should to change it in their modules.

Forms can set a default value.
http://api.drupal.org/api/file/developer/topics/forms_api.html

I know this.

Having it grab that default value is a nice feature.

Thanks.

I would take this up to core and see if this functionality (#default_value grabs variable name if not set in $form) can make it into the Forms API standard.

Only for options form, so that should be done in "system_settings_form()".
I think, that whole module could be integrated to core.

All above is my 'imho'.

Except these features this module provide other usefull features that I mentioned at my previous post:

• To specify structure and default values of all module settings in one place
• Automatic consistency check
• To operate with all settings without need to use data tables directly.

Now I'm working on:

• structured settings
• automatic convert enumerations like "item1, item2, item3" to array('item1', 'item2', 'item3') and vice versa
• ability to use this module functions without need to manually specify module name (if this possible)