|
|
.. _roadmap:
|
|
|
|
|
|
===================
|
|
|
Development roadmap
|
|
|
===================
|
|
|
|
|
|
IPython is an ambitious project that is still under heavy development. However, we want IPython to become useful to as many people as possible, as quickly as possible. To help us accomplish this, we are laying out a roadmap of where we are headed and what needs to happen to get there. Hopefully, this will help the IPython developers figure out the best things to work on for each upcoming release.
|
|
|
|
|
|
Work targeted to particular releases
|
|
|
====================================
|
|
|
|
|
|
Release 0.10
|
|
|
------------
|
|
|
|
|
|
* Initial refactor of :command:`ipcluster`.
|
|
|
|
|
|
* Better TextMate integration.
|
|
|
|
|
|
* Merge in the daemon branch.
|
|
|
|
|
|
Release 0.11
|
|
|
------------
|
|
|
|
|
|
* Refactor the configuration system and command line options for
|
|
|
:command:`ipengine` and :command:`ipcontroller`. This will include the
|
|
|
creation of cluster directories that encapsulate all the configuration
|
|
|
files, log files and security related files for a particular cluster.
|
|
|
|
|
|
* Refactor :command:`ipcluster` to support the new configuration system.
|
|
|
|
|
|
* Refactor the daemon stuff to support the new configuration system.
|
|
|
|
|
|
* Merge back in the core of the notebook.
|
|
|
|
|
|
Release 0.12
|
|
|
------------
|
|
|
|
|
|
* Fully integrate process startup with the daemons for full process
|
|
|
management.
|
|
|
|
|
|
* Make the capabilites of :command:`ipcluster` available from simple Python
|
|
|
classes.
|
|
|
|
|
|
Major areas of work
|
|
|
===================
|
|
|
|
|
|
Refactoring the main IPython core
|
|
|
---------------------------------
|
|
|
|
|
|
Process management for :mod:`IPython.kernel`
|
|
|
--------------------------------------------
|
|
|
|
|
|
Configuration system
|
|
|
--------------------
|
|
|
|
|
|
Performance problems
|
|
|
--------------------
|
|
|
|
|
|
Currently, we have a number of performance issues that are waiting to bite users:
|
|
|
|
|
|
* 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, such as using a
|
|
|
sqlite database to store this state. This will also help the controller to
|
|
|
be more fault tolerant.
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
