Short term:

- Support transactions under MySQL.

- Support 'feature probing' via the rules for user interface and to
  determine whether to try to do things (like use transactions).  This
  is a broad idea and includes things such as returning a list of
  possible column types to the user interface or having a flag for
  supporting transactions.

- Robin Berjon suggested a single documentation 'page' that contains a
  list of all the method and what objects they apply to.  This has
  been started.

- Alzabo::ObjectCache::DBIStore - this module will also do syncing all
  in one.  This will allow the caching/syncing to occur across
  multiple machines with multiple processes.

- Alzabo::ObjectCache::RDBMSStore.

- Alzabo::ObjectCache::BerkeleyDBSync - this should be much faster
  than the DB_File module, which spends a lot of time tying and
  untying a hash.

- Expand regression tests for core API - SQLMaker, RDBMSRules.

- After conversion, make local $table->{prefetch} work (tied scalar).
  I'm no longer sure this is possible.  My most recent attempt caused
  inexplicable test failures.

- Give the options to save objects to disk in something a bit more
  robust than a serialized object form.  Barrie Slaymaker is working
  on a generic XML language for database schema modelling, to be
  called DBML.

- Non-Mason interface (curses, plain CGI)

- Make caching system more atomic.  I'm sure there are subtle race
  conditions in there that should be fixed (timestamps are generated
  more than once, which could be a problem, for one).

- Support transactions in the caching system.  this eventually means
  real transactions at the middleware layer.  argh!

- Switch to cardinality/dependency concepts for ForeignKeys.
  Internals I'm not worried about as much as external API and language
  (in www interface, for example).

Medium term:

- Add an Alzabo::Database class between the schema and table.  This
  will allow multiple database (on multiple platforms ideally) and
  allow you to do joins between these databases.  This probably raises
  all sorts of horrid caching and transactional issues I haven't yet
  thought of.

- Attempt to guess relationships when reverse engineering a schema
  without foreign key information.

- Support any and all SQL, of arbitrary complexity.  This is actually
  a decent part of the way there already.

- Rewrite data browser to not suck so much

- Expand data browser to be configurable between sessions (for
  example, to use textarea fields for certain things)

- Help text for all interfaces (some of it should be shared since the
  basic ideas are the same)

- More drivers & rules (Oracle, Sybase, Interbase, Solid, and so on)

Long term:

- GUI (preferably both UNIX & Win32 so Tk?)
