Badger::Class
-------------

* Also think about different debug flags, e.g. DEBUG_THIS, DEBUG_THAT
  UPDATE: Badger::Debug now does this - just need to hook class in

* make debug hook work better: allow import of other items, e.g.
  debug => ':dump'.  Also generate DEBUG constant using any existing
  value of $DEBUG.
  
* AUTOLOAD method to delegate to real class if possible?

* add 'hook' subroutine attribute 

* add a way for B::C subclasses to register hooks that automatically
  get called on import, e.g. for B::Factory::Class to push base()

* Remove class($class, $target) second argument in export hooks
  because UBER should now handle that - needs testing
  UPDATE - no, I think it's still required to make The Right Thing happen.

* Make CLASS static.

* Change message() to snippet()
  NOTE - already changed Badger::Base XXX_msg() method to explicitly 
  package-scope message() to Badger::Base so that problem is mitigated.
  A subclass can now define a message() method and it will still Just Work[tm]


Badger::Codec
--------------

* encoded()/decoded() methods (e.g. for utf8)

* update docs to clarify the fact that utf8, etc., are available as named
  codecs via Encode/Encoding modules.


Badger::Config
--------------

* Just a basic implementation at moment.  Merge in TT3 config, AppConfig
  and other stuff.


Badger::Class::Config
--------------
  
* Add 'constant' as alias for 'method'.  e.g. 'FOO|class:FOO|constant:FOO'


Badger::Debug
-------------

* See if we can make this a low-level mixin that we can import into 
  Badger::Utils et al.
  
* make debug enabler export :debug and :dump into module


Badger::Docs
------------

* Finish writing it / cleaning it up and release.


Badger::Exception
-----------------

* Do we still want to add a higher-level catch() method?


Badger::Factory
---------------

* Subclass out into base class (returns loaded module name), object
  creator, object creator + cache (e.g. for hub), or whatever.

* have it bind fetch methods to item/items if undefined, e.g
  node => item, nodes => items.

* support multi-element names, e.g. node.foo.bar


Badger::Filesystem
------------------

* directory files/directories/dirs as grep across children

* need to handle encoding better in read_file() and write_file() methods.

* read-only filesystem option

* write_file() should have an option for writing to a temporary file and
  renaming into place to avoid race conditions.

* I'm considering refactoring this.  I'd like to unify the different
  filesystem-specific formats to an underlying URI-based one.  It would
  require a lens (combined parser + presenter) for each O/S.  Unix (inc
  Mac OSX) are simple, Win32 isn't hard.  Delegate to File::Spec for 
  everything else.

  Some info about Win32 path <-> uri translation, snarfed from 
  http://blogs.msdn.com/ie/archive/2006/12/06/file-uris-in-windows.aspx
  
  For the UNC Windows file path
     \\laptop\My Documents\FileSchemeURIs.doc

  The corresponding valid file URI in Windows is the following:
     file://laptop/My%20Documents/FileSchemeURIs.doc

  For the local Windows file path
     C:\Documents and Settings\davris\FileSchemeURIs.doc

  The corresponding valid file URI in Windows is:
     file:///C:/Documents%20and%20Settings/davris/FileSchemeURIs.doc 
  
  Functions currently used from File::Spec are: catpath, catdir, 
  canonpath, splitpath, splitdir, filename_is_absolute, abs2rel, 
  no_upwards.  Most of those can be moved out to lenses.  Path 
  manipulation becomes much easier internally when the path can be
  stored as a list of path nodes.


Badger::Log
-----------

* Add code to detect Log::Dispatch objects and forward messages.


Badger::Storage
---------------

* This is available in the git repository but not yet included in the released
  distribution.

* unify parameter parsing and identity definition between filesystem and
  database storage modules.

* get/put which take data / return id

* fetch/store which returns 

* create/destroy   connect/disconnect  open/close


Badger::Test
------------

* Could do with some proper testing.  Although all the other test scripts
  do tend to thrash it quite well...

* Change if_env to use Badger::Logic so we can specify things like:
      if_env => 'RELEASE_TESTING or AUTOMATED_TESTING'
 


Badger::Utils
-------------

* hashlike, listlike, numlike


BadgerX
-------

* add path to any bases missing it

* document



Longer Terms Goals / Larger Projects
------------------------------------

* incorporate re-write of AppConfig into Badger::Config

* consider doing the same with Pod::POM into Badger::Pod and combining
  with Badger::Docs.  (update: doing now)

* Finish cleaning Badger-Web and release

* Finish refactoring Badger-Database and release