====== Marks Scratchpad =======
===== Returning Objects =====
  * How about adding a method that returned a recordset as a JSON object. Been doing a lot of work recently with ajax feeds of jquery plugins, and have to hand craft them all.
  * Add a feature above to return as a google datatable
  * The recordset could provide headers from the metacolumns, so we could get cols and rows. This is similar to the rstohtml function, i think. Maybe it should just be an unsupported addon
===== Pear Compatibility =====
John tried to have a set of methods that were compatible with pear mdb, which seems to have been replaced by mdb2. Should we create an mdb2 compatibility module, so we could do e.g.
<code php>
use \ADOdb\pear\mdb2
</code>
or whatever...
===== serverInfo =====
Server info should return consistent number of keys as well as names in associative mode. 
===== Namespace idea =====

  Vendor = ADOdb
  Package Names = abstraction,activerecord,datetime,session

autoload order

  - abstraction\connector\
  - abstraction\recordset\
  - abstraction

  \ADOdb\abstraction\connector\mysql

  /adodb/abstraction/connector/mysql.php extends /adodb/abstraction/connection.php

This is autoloaded by the connector
  \ADOdb\abstraction\recordset\mysql

This would be sufficient to use the database abstraction class. This would be what i imagine what the lightweight class would be. 

The main class would have all the necessary class methods, but e.g. would load extra classs as needed:
<code php>

class \ADodb\abstraction\connection
{
    public function cacheExecute($args)
    {
    if not class loaded class \ADodb\abstraction\caching
      $this->c = new \ADodb\abstraction\caching;
      
    return $this->c->connection($args);
    }
}
</code> 
To add all the functionality to the we would have to load :

  \ADOdb\abstraction\datadict\mysql 
  \ADOdb\abstraction\helpers
  
===== Bringing the $db connection into other classes =====
Would we always pass the database connection in via the constructor? or via a setDatabaseConnection method after instantiation? I've often made stuff like this available via a global, e.g. 

  $GLOBALS['_ADOdbConnection'] = $db; 
  
I've no idea if its frowned upon in OO style coding. It would have to have a unique naming convention for multiple DB connectors

==== Note 02/02/2016 ====

Just found that this is the way it is done in te existing sessions management using a $GLOBALS['ADODB_SESSION_CONN'] connection