* configuration file
    * need to be able to specify:
        * regular options
        * typemaps
        * extra libs to load
        * GIN extractors

* Backends:
    * BDB/DBI
        * Set::Object/Hash sharding (each key/member is an entry in the BDB
          hash). This allows finer grained commits (e.g. insertion to a set
          simultaneously will not cause a failed transaction). Will BDB even
          allow transactions to do that? probably with MULTIVERSION, because
          the read won't block
    * RDF
        * generate triples
            * predicates as FQ attr names names
            * predicates as short attr names
            * predicates as UUIDs?
            * no collapsing by default
        * SPARQL matching with simple search

* concurrency test fixture for backends
    * forks
    * threads

* event based
    * linker is almost ready to integrate event based linking
    * if backend returns a cond var for get() then we can return a cond var for
      the whole graph. start with an api for it, and slowly implement actual
      async behavior using a backend role
    * AnyEvent::BDB, Files and CouchDB backends could benefit
    * skeptical about performance of DBI with forking
    * does the live object scope still make sense? probably, but it's much
      easier to leak it. the event oriented wrapper should keep live object
      scopes for the user at least for the duration of a callback, in
      additional to the user tracking to minimize confusion. $lookup->recv
      could return the scope into which the objects were loaded, along with the
      results

* threading
    * what happens with a shared KiokuDB directory? i don't think that's a good
      idea... better that each thread has its own copy? how can we guarantee
      recursive thread sharing of passthrough/callback objects?

* typemap
    * DB resident metaclass? like a smalltalk image
	* class version upgrade path as part of class field

* query
    * http://www.ietf.org/rfc/rfc1960.txt

* GC schemes
    * Online schemes
        * entries can already enumerate what they refer to
        * refcounting is one option
        * rel index table is another
            * all references are cross referenced in a table that can be also
              used to list backrefs. In SQL this table can have delete triggers
              i guess (ask mugwump), in BDB this would be manual.
        * incremental scheme
            * parrot's tricolor garbage collection alrogithm is interesting
                * the data could be partly maintained during store/delete
                  operations, with a partial sweep performed every time some
                  statistic is tipped
            * generational GC could make sense here, due to the persistence of the data
    * Offline schemes
        * mark & sweep
            * LinkChecker
            * tri-color using some auxillary table
    * collection of clusters of data: http://www-sor.inria.fr/publi/GC-PERS-DSM_POS94.html
    * http://pauillac.inria.fr/~lefessan/dgc/
    * http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.663
    * transactional ref counting: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.2363

* XS acceleration
    * LiveObjects
        * custom uvar magic instead of Scope::Guard all over
            * should provide significant speed & memory consumption
              improvements
    * Linker
        * inflate_data is actually really ugly in Perl, could be
          smaller/faster/cleaner in XS
    * Data::Visitor
        * Collapser
        * jspon?
        * $entry->references