WHEN ONLINE

* Publish Cache::Benchmark results comparing CHI and non-CHI caches for File, FastMmap, Memcached - where?
* Delete chi svn, point to git
* Set up automatic email to perl-cache group on every release (figure out how to mail from mac!)
* http://perl-cache.sourceforge.net/ - still leans heavily towards Cache::Cache - do we need our own site?
* Send patch to Cache::FastMmap re corruption - see email from Rob Mueller 1/6/09

SIZE AWARE RELATED

. Add item limit to memory cache - FIFO or LRU - look at existing modules, perhaps just
  use one of those if well implemented
. Make remove(), clear(), and get_keys() wrappable
* Allow size limit to be expressed in bytes, megabytes etc. - reverse of Number::Format
* Add replace(), which only replaces an existing value by a computation based on that
  value - by default does a get and set
* Log removes

PAIRED CACHE RELATED

* Add standard test to t/Driver.pm that creates the driver being tested with an l1_cache
* Test set_multi with memcached and an l1_cache/mirror_to_cache
* Call call_method_on_subcaches for 'clear'
* Document l1_cache, mirror_to_cache

TO DO

* Serialization
  * Use raw Storable by default
  * When passing string as serializer, use raw=>1
  * serializer should be passed from multilevel parent to children
* Switch to Mouse instead of Moose, depend only on Mouse
. Do we need expire() and expire_if() as functions, really? Cache::Cache didn't have expire(), and it is generally better to remove() than expire() (and has the same effect anyway). Deprecate?
  . Well, expire() could be useful for some if they want the old value to remain there, so just put a warning in docs that remove() is more efficient. expire_if() can be deprecated.
* Make it easy to designate l1 cache and clone-to cache that DWIM - either with Multilevel and a way to designate methods, or with properties like l1_cache (pre_cache?), backup_cache (post_cache?), and clone_to_cache properties. Maybe it is better to have a primary/secondary relationship as opposed to multilevel's equal partner relationship.
* get_multi_arrayref should be defined in terms of fetch_multi_arrayref, whose results are then passed along to get() with the data param.
* Stats collection - with collect_stats flag, collect stats in global object (one per process), output when object gets destroyed or at certain intervals
* Built-in memoization of cache objects (gated by first class property - see how Rose does them)
  And/or fix Mason $m->cache() to memoize cache object, at least with no arguments - taking care to react to changes in default_cache_options
* Built-in registration of storage types, like Rose's register_db(domain => 'development', type => 'main') - just expands parameters - must work with memoization
* Built-in find-based file purge for File driver
* DBI driver (at least mysql) - keep pestering Perrin
  Justin's - http://github.com/jdv/perl-chi/tree/master
* Write Log::Any, and convert CHI and Mason to use it
* BerkeleyDB driver (w/separate file per namespace, must handle locking)
* Allow FastMmap, BerkeleyDB, etc. drivers to easily work with either one file or a directory
  namespace_mode => ['native' - normal, 'fold' - fold into key, 'ignore' - don't use namespaces at all, error to specify]
  OR - when FastMmap and BerkeleyDB are given a file, automatically fold into key, and don't support get_keys and get_namespaces
* Marketing through contribution of CPAN modules --
  * CHI plugins for Catalyst, CGI::Session
* expire_if_files_changed(...) - returns an appropriate expires_if pair - CHIx::ExpireByFile or similar
* expires_next => ['hour', 'day']
* compare strategies for reducing miss stampedes in docs
* Test:
  * bad driver
  * default settings for $cache object: expires_at, expires_in
  * dir_create_mode and file_create_mode in File driver (test only under Unix)

POSSIBLY

* Do auto-key-digesting for too-long keys - eliminates max key length - can work regardless of driver, but each driver can have its own default max key length, and will have to store key inside metadata in just this case - is it worth it?
* Add cache signature, encapsulating CHI's metadata version and options to the driver, as a second differentiator alongside namespace
* Create faster get_object variant that does not support value - e.g. so file cache can read just metadata - then use this variant for get_expires_at, etc.
* Handle unicode chars in escape_for_filename by utf8 encoding when needed (but how to know when unescaping...) - is it worth it? Did Cache::FileCache handle unicode keys?
* support key escaping for any drivers that need it, e.g. memcached (via parameter, default on)
* background compute
* implement read-only and write-only caches (useful for multilevel caches)

QUESTIONS

* Which drivers (memory, file, fastmmap, memcached) should we include with CHI, and which should we release separately?
* Is there a value to separating out the constructor to CHI->new, and putting everything else in CHI::Driver, other than that it is vaguely DBI-like?
* What should set() return? The value? Success flag? Cache::Cache doesn't seem to specify.
* Should we auto-remove items after a miss, like Cache::Cache? Or is this silly b/c it will probably be followed with a set?
* Should namespace default to caller package?
* What happens if a reference is passed as a key? Stringify reference, or reject, or serialize automatically to a key?
* Should get_namespace() always/sometimes/never report empty namespaces - i.e. namespaces that have been created but not populated, or namespaces that have been cleared?
* Should multilevel driver be renamed - potential confusion with get_multi_*, set_multi, etc.?
