--------------------------------------------------------------------
TODO      DOTODOTODOTODOTODOTODOTODOTODOTODOTODOTODOTODOTO      TODO


If anyone is interested in contributing to the feature set, please
subscribe to the perl-objectstore mailing list.  Send email to
majordomo@parallax.co.uk with the following in the body of the
message:  "subscribe perl-objectstore you@your.company.com"


Optimize for flexibility, then memory performance, then speed.

1. Flexibility
Flexibility is the most important because ObjectStore should be
easier to use and everyone complains that it can't do SQL.
We'll show 'em!

2. Memory Performance
Memory performance is also very important due to the potential size of
databases.  Small memory efficiency improvements in a 5TB database
have a big impact.

3. Speed
Speed is pretty good already, compared to a relational database!
Of course, there is always room for improvement.


+ FOR CORE SCHEMA EVOLUTION +

Weak references!

Don't store the hash key's length in the database (save 4 bytes and an
allocation)!


+ IDEAS +

$hv->new_cursor($seg);

Persistent cursors!

osp_copy -> database cursor (focus)

Factor Peeker

Tk osp_edit?

Support for acquire_lock(), transaction hooks, notification, database
access control, utility API, os_object_cursor?  Who cares?

Split GENERIC into ObjectStore & Splash parts?

ObjStore::File.  Support Verity full text indexing?

Encapsulate all the transaction stuff.  Figure out nested transactions.

ObjStore::Transaction::Bridge as a perl object?

Track down any/all XS transient memory leaks.  (Any?)

Avoid stomping on some other version of bless?


+ BIGGISH PROJECTS +

Support for multiple application schemas!  (Expected 1Q98)

Add support for parts of the TimeSeries Object Manager?

Could perl performance be improve?  Streamline typemap?

Add MOP support for editing & reporting of abritrary databases. [HARD]
Object Design working on this problem?

Expand Maker to encompass all architectures/compilers/situations.


+ CORE-PERL WISH LIST +

According to Devel::Peek, tied hashes/arrays take up transient memory
proportional to their underlying structure.  This needs to be fixed!

There should be a less kludgy way to extend bless.  Why isn't it a
special method of UNIVERSAL?  :-(

Why do FIRSTKEY, NEXTKEY accept a string instead of a (string, length) pair
or an (SV*)?  The TIE interfaces should be more XS friendly!

Make 'reftype' an official built-in!


