gistfile1.perl

    - Test 1 or 2 more apps
    - write tests for getting default_model / default_view from config?
    - move block from sub controller to Catalyst::Utils
    - kill components class data
        - kill initialization in sub setup
        - kill duplication: http://paste.scsys.co.uk/123648
        - create a sub components that returns all components
        - merge with around components => sub {}
        - locked hash (Hash::Util)
    - block inside sub setup:
        Fix me to be a method on the container? (Or at least get a) data
structure back from the container!!
        ( t0m: My only thought really is that maybe it should call
$c->container->something,
        rather than $c->components, which is/will be implemented in terms of
$c->container->something anyway )
    - kill $c->comp('MyApp') (confirm with t0m)
        - Catalyst::Exception "You called $c->comp('MyApp') and deserve to
die in a fire" :)
        - fix unit_core_plugin.t
    - kill myapp as controller
        - sub MODIFY_CODE_ATTRIBUTES { die("Catalyst applications (aka
MyApp) cannot be controllers any more.. etc etc") }
    - move _find_component to container
    - 'This behavior is going to be deprecated in future releases' -> 
'This behavior is deprecated, and will be removed in a future release'
    - deprecate ->component returning list
        - create sub component_list?
    - take a look at setup_component. sub COMPONENT being called twice.
    - fix helper (order of statements)
    - write tests for apps using ConfigLoader and ConfigLoader::*
    - ->comp(qr/::M::/) will search ->components
    - mv live_view_warnings.t => live_mvc_warnings.t (model and controller
too)
        - fix the test so that it looks for the correct warning
    - kill search_extra (also confirm with t0m. Some people answered they
were using it, right?)

Aside from that, next big steps would be:

    - Write documentation
    - Move stuff in setup / setup_component / setup_components /
locate_components down to the Container
    - make BB handle plugins
        - replace C::P::PluginLoader
            instead of Catalyst::Plugin::PluginLoader support something like
config for MyApp::Web, maybe have a key like plugins, roles, etc? (container
role, or something similar)
    - make hard things easy (models that share the same config)

On this last item, are these things below (from the proposal) possible
already? If not, how could I do them?
    - It would make it easier to separate application code from the specific
Catalyst bits. That way, the code can be wired to Catalyst as a webapp just
as easily as to a crontab script.
    - Users of the Catalyst framework, that is, application developers, will
be able to define how components are instantiated, and their lifetime. That
would remove the need for Catalyst::Component::InstancePerContext and
Catalyst::Model::Adaptor, for example. Also, it would be possible to define
components without the actual file existing, as implemented in
CatalystX::DynamicComponent::ModelsFromConfig.