I realized that if every module has their own settings that would make a bazillion windows to open to configure the bot when setting it up.

I was thinking about an access settings window similar to the security settings so that you can configure access to all modules on the same page. That way you don't have to open one window to set up News and one for MassMsg and one for privgroup relay.

It would be something like:

Relay_Access_Toggle:  GUEST
  Description: Who should be able to toggle relay on/off
  Change to: [ ADMIN | LEADER | MEMBER | GUEST | ANONYMOUS ]

MassMsg_Access_Send:  LEADER
  Description: Who should be able to send mass messages
  Change to: [ ADMIN | LEADER | MEMBER | GUEST | ANONYMOUS ]

Mail_Access_Read:  GUEST
  Description: Who should be able to read mail
  Change to: [ ADMIN | LEADER | MEMBER | GUEST | ANONYMOUS ]

Mail_Access_Send:  MEMBER
  Description: Who should be able to send mail
  Change to: [ ADMIN | LEADER | MEMBER | GUEST | ANONYMOUS ]


However it would be nice to be able the same settings from both this common window _and_ individual module settings. But that would require rewriting of the security module.

Any thoughts?

If we had a lot of modules using Glara's settings it would be spammy in my opinion.  Imagine having APF alerts and Quotes alerts on the same page, it would also look confusing I think...

I have about 9 modules using the new settings interface and it's much better to have them seperate.  Of course, having an option to change between different styles of interface would suit both :-)

I think he's talking about lower level access Alreadythere, ie. !mail would be controlled by the security module, !mail read and !mail send by the module itself (i much prefer the freedom of settings in this case than hardcoding into the module).

-jj-

I feel that I am being a bit misunderstood here so I'll attempt to clarify what I am meaning:

Say you've got a couple of modules with settings windows like

Settings for Mail

Access_Read:  GUEST
  Description: Who should be able to read mail
  Change to: [ ADMIN | LEADER | MEMBER | GUEST | ANONYMOUS ]

Access_Send:  GUEST
  Description: Who should be able to send mail
  Change to: [ ADMIN | LEADER | MEMBER | GUEST | ANONYMOUS ]

Life_Read:  2 weeks
  Description: How long should a read message be kept?
  Change to: [ 1 week |  2 weeks |  1 month |  6 months |  1 year |  2 years ]

Life_Unread:  6 months
  Description: How long should an unread message be kept?
  Change to: [ 1 week |  2 weeks |  1 month |  6 months |  1 year |  2 years ]

Logon_Notification:  On
  Description: Notify about new messages at logon
  Change to: [ On | Off ]

and

Settings for Relay

Access_Toggle:  GUEST
  Description: Who should be able to toggle relay on/off
  Change to: [ ADMIN | LEADER | MEMBER | GUEST | ANONYMOUS ]

Status:  On
  Description: Relay to private group should be
  Change to: [ On | Off ]

Now when setting up the bot one would probably want to review the access levels of all modules, thus instead of having to open every module window separately one could have a common window for access settings that would (for the two above examples) look like:

Module access settings

(Mail) Access_Read:  GUEST
  Description: Who should be able to read mail
  Change to: [ ADMIN | LEADER | MEMBER | GUEST | ANONYMOUS ]

(Mail) Access_Send:  GUEST
  Description: Who should be able to send mail
  Change to: [ ADMIN | LEADER | MEMBER | GUEST | ANONYMOUS ]

(Relay) Access_Toggle:  GUEST
  Description: Who should be able to toggle relay on/off
  Change to: [ ADMIN | LEADER | MEMBER | GUEST | ANONYMOUS ]

Ie. it would only provide settings that control access and not other aspects of each module.


I hope that clarifies things.

Also it would be nice if each setting or module had an access level tied to it so that one could configure certain settings to be modifiable by ie. members while other settings are reserved for admins and others again are reserved for superadmins. That would make the settings module much more versatile.

Any thoughts on how this could be implemented?

Add an access_level column to the database with the access level required to change the setting. Default level is admin. Modify the create function to accept access level...

Then I'd add another array to the settings module to cache access levels.
$this -> access_level['Module']['Setting'] = ADMIN;

Modify the save function to respect access levels...

I think that would do it.

What one could do is to abstract a base module that defines stuff common to all (read: most) modules.

I find this to be "a good idea"(tm) for the following reasons:
  * most commands reply to the channel in which the command was issued
  * saves exact duplicates in modules
  * may or may not save memory as the abstracted methods are only held in one place I think
  * Provides an out-of-the-way place to define Access_control variable for the module
  * Provides $this -> module_name which is usable atleast in the constructor
  * Provides a place to impliment an in-module help system. (Needs more thought tho)
  * Reuses the settings interface to control access levels thus eliminating the requirement for a separate GUI. (Even if a special handler for Access_control module in settings that would list all access control settings would be handy)

This may be a bad idea because
  * If memory is allocated for every class that extends a base module (which I don't think it is) then memory is used for unneded command handlers where some channels are not used
  * Causes needs of revamp for all modules even if the need is not immediate (ie. doesn't break old modules for other things than the access_control)
  * The default handlers are somewhat hidden and it may cause confusion for module developers even with the explination of how to re-define default handlers.

In addition of requiering alterations similar as to what Allreadythere has made to bot.php for access control the new module structure requires the mentioned alteration to the settings-gui.

The proposed core/Basemodule.php looks like this:

<?php

/*******************
 core/BaseModule.php
********************/
abstract class BaseModule
{
var $bot;
var $module_name;

function __construct (&$bot, $module_name)
{
//Save reference to bot
$this -> bot = &$bot;
$this -> module_name = $module_name;

//Create Access_control setting for this module (NEEDS TO BE CONFIGURED BEFORE COMMAND IS ENABLED)
$this -> bot -> set -> create ($module_name, "Access_control", "UNDEFINED", "Who should have access to this command", "SUPERADMIN;ADMIN;LEADER;MEMBER;GUEST;ANONYMOUS");
}

/************************************************************************
 Default to replying in the same channel as the command has been recieved
*************************************************************************/
public function gc($name, $msg)
{
$reply = $this -> command_handler($name, $msg, "gc");
if ($reply <> FALSE)
$this -> bot -> send_gc($reply);
}

public function tell($name, $msg)
{
$reply = $this -> command_handler($name, $msg, "tell");
if ($reply <> FALSE)
$this -> bot -> send_tell($name, $reply);
}

public function tell2($name, $msg)
{
$reply = $this -> command_handler($name, $msg, "tell2");
if ($reply <> FALSE)
$this -> bot -> send_tell($name, $reply);
}

public function pgmsg($name, $msg)
{
$reply = $this -> command_handler($name, $msg, "pgmsg");
if ($reply <> FALSE)
$this -> bot -> send_pgroup($reply);
}

//Prototype for the command_handler
abstract protected function command_handler($name, $msg, $origin);

//Implementation of a show_help() function. $this -> help_window would be defined in the module definition.
//Making a $this -> bot -> make_help(modulename, text); wouldn't be all whack as it can impliment a common
//header for all help windows. Not entirely sure of how this would be called tho.
public function show_help()
{
$this -> bot -> send_tell($this -> bot -> make_blob($this -> module_name, $this -> help_window));
}
}
?>

And an example module would then look like:

<?php
//snipped out lots of comments to save some space
$testclass = new TestClass($bot);

$commands["tell"]["testing"] = &$testclass;
$commands["pgmsg"]["testing"] = &$testclass;
$commands["gc"]["testing"] = &$testclass;

/*
The Class itself...
*/
class TestClass extends BaseModule
{
/*
Class variables (static) are defined here
*/
var $help_window;

/*
constructor. Hands over a reference to the bot and sets default actions for commands
*/

function __construct (&$bot)
{
//call base module constructor
parent::__construct(&$bot, get_class($this));
//Set a sensible default for Access_control if none has been set yet.
if($this -> bot -> settings[$this -> module_name]['Access_control']=='UNDEFINED')
{
//If this is omitted access to the command will be disabled until configured with either !settings Access_control or !settings modulename
$this -> bot -> set -> save ($this -> module_name, "Access_control", "MEMBER");
}

//create other settings for this module
$this -> bot -> set -> create ($this -> module_name, "SettingName", "DefaultValue", "This a setting used with the settings module", "DefaultValue;OtherValue");

//Define the help window text here
$this -> help_window = "This module really doesn't do anything very useful.";
}

/******************************************************
 Implement the command handler referenced by BaseModule
*******************************************************/
protected function command_handler($name, $msg, $origin)
{
//Here you would normally parse $msg and act accordingly. For this test class tho, just send a reply
return("{$this -> module_name} is responding to command '$msg' sendt via $origin by $name.");
}

/********************************************************************************************************
 It is possible to redefine the default command handlers here to they do something other than the default
*********************************************************************************************************/
//When command is recieved via gc reply in a tell instead of spamming gc
public function gc($name, $msg)
{
$reply = $this -> command_handler($name, $msg, "gc");
if ($reply <> FALSE)
$this -> bot -> send_tell($name, $reply);
}

/*************************************************************************************************************
 Non-command hooks (leave them in module because there's "no sensible default"(tm) availible for such handlers
**************************************************************************************************************/
function privgroup($name, $msg){}
function gmsg($name, $group, $msg){}
function pgjoin($name){}
function pgleave($name){}
function buddy($name, $msg){}
function cron(){}
function connect(){}
function disconnect(){}

/*
Custom functions go below here
*/



}
?>

What do you think about splitting it up like this? I am undecided on putting the different handlers in the base module. They might just as well might be keept in the modules even if it causes redundant code.

According to http://auno.org/dev/aochat.html so does the latest aochat.

Update! Nov 25 2005
revision 1.18
. Requires PHP 5 (for new object model).

Hmm.. Odd.

But yes, you are right. The new objects are not supported under php4.

So we'll hang an eventual overhaul on the wall until PHP5 is more widely deployed then.

But yes, you are right. The new objects are not supported under php4.

So we'll hang an eventual overhaul on the wall until PHP5 is more widely deployed then.

Khalem and I discussed php4 vs. php5 and Khalem's opinion was that we should continue to support php4 for the 0.4 release unless there was a critical reason to move to php5. AOChat only working in php5 would be a critical reason.