-- Diagram producer could benefit from some real graphing algorithms to
- better distribute the boxes.
+* The regular Sybase parser is only just functional. If you are
+ interested in using Sybase, I would suggest serializing the schema
+ (via YAML or Storable) using the DBI-Sybase parser and then
+ manipulating that as you see fit.
-- Some way to deeply check to schema objects, e.g., for testing I
- parse a MySQL schema, translate to Oracle, then parse the created
- Oracle schema and want to check the two schema objects.
+* Add more DBI parsers! These have the potential to be very
+ thorough and far faster than parsing text files with
+ Parse::RecDescent.
-- Add parsers and producers for Torque XML/DB schema
- (http://db.apache.org/torque/)
+* At least allow more pass-through of INSERT, DELETE, and UPDATE
+ statements
+
+* Add INSERT statements for xSV, Excel parsers to automatically
+ create INSERTs for each row of data in the source file
+
+* Somehow merge ClassDBI producer with CGI::FormBuilder or Template
+ Toolkit and some sort of automated CGI builder to create
+ view/create/edit/delete forms for objects based on schema defs
+
+* Embetter the Diagram producer to use some real graphing algorithms
+ to distribute the tables so that the lines don't overlap so badly
+
+* Integrate more with some standard XML schema representations,
+ maybe like Torque DB (http://db.apache.org/torque/). We've
+ started messing around with XMI, too, but it isn't quite usable.
+
+* Possibly write a basic ANSI-92 SQL parser which could be extended
+ when writing other new parsers.
+
+* Make as many "required" modules as possible optional. This will
+ require support in the Makefile, the tests, and the modules
+ themselves (they'll need to die gracefully if prerequisites are
+ not installed).
+
+* Support for precompiled Parse::RecDescent grammars.
+
+* More code generation producers, such as Java, PHP, and Python.
+
+* Integrate Module::Pluggable as a replacement for the _list method.