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


If you are interested in contributing, subscribe to the OS/Perl
mailing list.  Send email to majordomo@parallax.co.uk with the
following in the body of your 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.


+ IDEAS +

nuke -lC

begin wantarray

_Per_segment_data is not free'd when no longer needed

Threads support!

Write up 'tight vs. loose binding' for ObjStore.pod

Peeker fix comma & semi // fix for "$at = " prefix

Support for notification, database access control, transaction hooks?

posh
  sync_INC on reopen
  special case 'chdir database' for blessed databases & $at->open('mvcc')
  create empty databases
  Devel::Symdump->methods when peeking if blessed?
  multiple instances per user
  peek directly to STDOUT

osp_copy - get rid of the -step option.


+ VAGUE POSSIBILITIES +

posh
  use posh as a front-end for utilities?
  call system() when in ufs?

TRANSIENT ObjStore::Ref ?

Reference weaken/strengthen?  Use some bits in OSSVPV?

Split GENERIC into ObjectStore & Splash parts?

depreciate os_object_cursor?

ObjStore::File.  Support Verity full text indexing?

Seems like there might be memory leaks on the transient side...?

Make XS code more efficient.  (How?)


+ BIGGISH PROJECTS +

Makefile.PL ?? (yuk)

For arrays, how about a tree of array slabs where slab size is
proportional to cardinality?  It's not O(1), but it should
be close enough for small data sets.  Big data sets are slow anyway.

Find replacement for os_dictionary that is lighter weight
(liboscol.so.sun.4.0 is 2.7M of code & 200k of schema), uses less
memory, does in-order traversals roughly sorted by address (?), and
has cursors that use references instead of pointers.  Also need
cursors that are seek'able and can find the distance between cursors.
Anything on the net suitable?  GE_COOL or AVL_Tree?  Any b-trees?

Support for multiple application schemas (expected 1Q98)

Add support for parts of the TimeSeries Object Manager?

Could perl performance be improve?  Streamline typemap?

Expand Maker to encompass all architectures/compilers/situations?
Makefile.PL?


+ CORE-PERL WISH LIST +

The TIE interfaces are not as detailed as the built-ins.  I should be
able to hide whatever necessary complexity in the module that
implements the 'tie' so the user doesn't have to know anything
special.  How about lvalues?  How about proper support for nested
structures?

Devel::Peek seems to indicate that hash-elements under a tied hash
are being allocated.  I don't understand how this could be necessary. 
Tied values should take an absolute minimum amount of transient memory. 
Why store things twice?

Make 'blessed' a built-in?
