doc: updated roadmap, which had become stale.

Also removed some remaining references to components, replacing with Configurables

docs/source/config/overview.txt

@@ -51,7 +51,7 b' Application: :class:`~IPython.config.application.Application`'
     Applications always have a `log` attribute that is a configured Logger.
     This allows centralized logging configuration per-application.
 
-Component: :class:`~IPython.config.configurable.Configurable`
+Configurable: :class:`~IPython.config.configurable.Configurable`
     A configurable is a regular Python class that serves as a base class for
     all main classes in an application. The
     :class:`~IPython.config.configurable.Configurable` base class is
@@ -121,10 +121,10 b' attributes on it. All you have to know is:'
 
 The answers to these two questions are provided by the various
 :class:`~IPython.config.configurable.Configurable` subclasses that an
-application uses. Let's look at how this would work for a simple component
+application uses. Let's look at how this would work for a simple configurable
 subclass::
 
-    # Sample component that can be configured.
+    # Sample configurable:
     from IPython.config.configurable import Configurable
     from IPython.utils.traitlets import Int, Float, Unicode, Bool
     

docs/source/development/roadmap.txt

@@ -27,13 +27,17 b' Release 0.11'
 * Prepare to refactor IPython's core by creating a new component and 
   application system (done).
 
-* Start to refactor IPython's core by turning everything into components
-  (started).
+* Start to refactor IPython's core by turning everything into configurables
+  (mostly done).
 
 Release 0.12
 ------------
 
-* Continue to refactor IPython's core by turning everything into components.
+* Continue to refactor IPython's core by turning everything into configurables.
+
+* Merge draft html notebook (started).
+
+* Add two-process Terminal frontend using ZMQ architecture.
 
 
 Major areas of work
@@ -44,78 +48,48 b' Refactoring the main IPython core'
 
 During the summer of 2009, we began refactoring IPython's core. The main
 thrust in this work was to make the IPython core into a set of loosely coupled
-components. The base component class for this is
-:class:`IPython.core.component.Component`. This section outlines the status of
-this work.
+components. The base configurable class for this is
+:class:`IPython.core.configurable.Configurable`. This section outlines the
+status of this work.
 
-Parts of the IPython core that have been turned into components:
+Parts of the IPython core that have been turned into configurables:
 
-* The main :class:`~IPython.core.iplib.InteractiveShell` class.
+* The main :class:`~IPython.core.interactiveshell.InteractiveShell` class.
 * The aliases (:mod:`IPython.core.alias`).
+* History management (:mod:`IPython.core.history`).
+* Plugins (:mod:`IPython.core.plugin`).
 * The display and builtin traps (:mod:`IPython.core.display_trap` and
   :mod:`IPython.core.builtin_trap`).
 * The prefilter machinery (:mod:`IPython.core.prefilter`).
 
-Parts of the IPythoncore that still need to be turned into components:
+Parts of the IPython core that still need to be Configurable:
 
 * Magics.
-* Input and output history management.
 * Prompts.
 * Tab completers.
-* Logging.
 * Exception handling.
 * Anything else.
 
-Process management for :mod:`IPython.kernel`
+Process management for :mod:`IPython.parallel`
 --------------------------------------------
 
-A number of things need to be done to improve how processes are started
+A few things need to be done to improve how processes are started
 up and managed for the parallel computing side of IPython:
 
-* All of the processes need to use the new configuration system, components
-  and application.
-* We need to add support for other batch systems.
-
-Performance problems
---------------------
-
-Currently, we have a number of performance issues in :mod:`IPython.kernel`:
-
-* The controller stores a large amount of state in Python dictionaries. Under
-  heavy usage, these dicts with get very large, causing memory usage problems.
-  We need to develop more scalable solutions to this problem. This will also
-  help the controller to be more fault tolerant.
+* Improve the SSH launcher so it is at least back to the levels of 0.10.2
+* We need to add support for other batch systems (LSF, Condor, etc.).
 
-* We currently don't have a good way of handling large objects in the
-  controller. The biggest problem is that because we don't have any way of
-  streaming objects, we get lots of temporary copies in the low-level buffers.
-  We need to implement a better serialization approach and true streaming
-  support.
-
-* The controller currently unpickles and repickles objects. We need to use the
-  [push|pull]_serialized methods instead.
-
-* Currently the controller is a bottleneck. The best approach for this is to
-  separate the controller itself into multiple processes, one for the core
-  controller and one each for the controller interfaces.
 
 Porting to 3.0
 ==============
 
-There are no definite plans for porting of IPython to Python 3. The major 
-issue is the dependency on Twisted framework for the networking/threading 
-stuff. It is possible that it the traditional IPython interactive console 
-could be ported more easily since it has no such dependency. Here are a few
-things that will need to be considered when doing such a port especially
-if we want to have a codebase that works directly on both 2.x and 3.x.
-
-1. The syntax for exceptions changed (PEP 3110). The old `except exc, var`
-   changed to `except exc as var`. At last count there was 78 occurrences of this
-   usage in the code base. This is a particularly problematic issue, because it's
-   not easy to implement it in a 2.5-compatible way.
-
-Because it is quite difficult to support simultaneously Python 2.5 and 3.x, we
-will likely at some point put out a release that requires strictly 2.6 and
-abandons 2.5 compatibility.  This will then allow us to port the code to using
-:func:`print` as a function, `except exc as var` syntax, etc.  But as of
-version 0.11 at least, we will retain Python 2.5 compatibility.
+Dropping 2.5 support was a major step towards working with Python 3 due to
+future syntax support in 2.6.  IPython 0.11 requires 2.6 now, so 0.10.2 will
+be the last IPython release that supports Python 2.5.
+
+We currently have a `separate repo <https://github.com/ipython/ipython-py3k>`_
+tracking IPython development that works with Python 3. The core of IPython does
+work, but the parallel computing code in :mod:`IPython.parallel` does not yet
+work in Python 3, though the only major dependency of the parallel code, pyzmq,
+does work on Python 3.
+