* Create a function that a SQL command with variables inserted can be passed to,
phpGACL will then replace the variables with ACL specific SQL and return the entire query
to be executed. IE:

$sql = "select * from table #phggacl_join# where #phpgacl_allow# limit 100 offset 10"; 
$retval = get_acl_sql( <ACO Section>, <ACO Value>, (ARO|AXO), <(ARX|AXO) Section>, $sql );

phpGACL would insert the proper SQL to join ACL tables at #phpgacl_join# and proper SQL
to limit the query to allowed entries only at #phpgacl_allow#. I think this is the best
solution to the huge amount of rows for acl_check() problem. 


* Have the Admin interface "show code" as it does operations.

* Create code that takes an ACL_ID as input arguments and returns example acl_check() code that will
hit the given ACL, regardless if it is ALLOW or DENY. This should really help people get started
with phpGACL.

* Create enviroment tests in test suite to check if the database has data in it or not.
* Create regression tests. - Need more of these.

* Write function to find which groups an object is in.
* Add ability to find all groups objects are assigned too in admin interface.

* Value is a reserved word on SapDB/MaxDB. Quote it.

* Make sure all input values in gacl.class.php are quoted. 

* Create upgrade.php script, to handle as much of the upgrade process as possible. Have it display the changelog as well?
	Have setup.php handle this?

* Array ACL Checks for select boxes. - Half done currently.

* Add visual notification when a section has hit the $max_select_box_items.

* Add filters/AXO's to ACL Test page.

* Oracle compatibility. XML Schema should fix the majority of the Oracle issues.

* FUTURE: Build framework for the plugin system.
    Create a "plugin" directory.
    Create a "plugin" section on the acl_admin page where plugin form fields can be displayed?
    Plugins must be enabled in the config file, for both the admin interface and the calling interface?

* FUTURE: Possibly support tree'd ACOs.

* FUTURE: Allow phpGACL to set permissions on its own administration interface. 
Having said that, I think going 99.9% of the way would be inside said scope and
would be something to seriously consider. We could add all the ACO's, ARO's, Groups, and 
mark them "system" so they can't be deleted, as well as all the acl_check()'s. 
Then in an include file or something we could place a hook to plugin with any 
existing login/authentication mechanism and disable all this by default. Once the
user enables it and plugs in a simple ARO value, it would all come to life and allow
them the ability to use phpGACL to set permissions on itself. 

* Write "mock" implementations to show off some of phpGACL's benefits.