Kepler 2.0 Release Roadmap

Goals for Kepler 2.0 release

Kepler 2.0 will introduce new features that make it upgradeable, extensible, and supportable in the field.  These features include a new modular extension system, module manager, build system, and repository structure. 

Our primary goal for the 2.0 release is to create a module system that allows the Kepler team and 3rd parties to contribute modules that extend Kepler's functionality.  These modules will be able to be loaded at runtime into Kepler, so both new modules and module upgrades can occur without requiring a new release of Kepler.  This will allow both Kepler participants and 3rd parties to release their own modules that extend or change Kepler's functionality without waiting for the next Kepler release.  These modules might include new suites of components that can be used to build workflows as well as new services and systems that are available within Kepler.

After Kepler 2.0 is released, we do not plan on rolling out any upgrades to the core system that require fundamental changes to how other modules interface with the Kepler.  Any upgrade of core functionality that requires all modules to be modified will be left for Kepler 3. Adding significant features between 2.0 and 3.0 is fine; taking them away (or providing a substitute that requires rewriting 3rd-party code or their configuration files) probably is not.

While we recognize that significant improvements in the usability of Kepler's user interface could be made, we have decided to postpone most of these types of changes until after the 2.0 release. The Kepler user interface architecture needs to be redesigned to provide additional extension capabilities, and our estimate is that this will take a significant period of time (> 6 months) before we can get community agreement on the goals, architecture, and implementation framework for a new user interface.  These changes will be a major focus of a future release.

In summary, the major goals for this release are:

• To create a stable release of underlying Kepler system
• To enable system extension and upgrade through a module system
• To provide continuity for 3rd party projects to be productive soon
• To enable frequent releases of new features through independent module releases

Focal deliverables for Kepler 2.0

Although there have been many changes to Kepler encompassing both bug fixes and enhancements (see the open bug and enhancement list, and closed bugs), there are some critical sets of features and changes that will define the release, as listed here.

• Module system (bugs 3948, 4340, 4009, 4338, 4317, 4345)
  •  packaging format, publishing system, module-manager (4340)
  •  minimal module configuration (3948)
  •  refactoring into sensible modules for later upgradeability (4246)
  •  separate actors into own modules (4341)
    •  Distinguish essential actors versus non-essential
• New build system (done)
• New system for Save/Open Kepler Archive (KAR) files (4515, 4150)
• Resolve KAR versus module format discrepencies (4340)
  • ability to specify dependency of KARs on modules (4317)
  • ability for module manager to install modules needed by KARs automatically (4516, 4483)
• Search (4517)
  • local search of directories, remote search of repositories
  • search for both components and workflows
  • ability to open workflows from Library
• Documentation (3976)

Configuration System Notes

For modules to be effective, they need to be able to be configured at run time.  They need to be able to store configuration properties about their own state, and they must be able to read configuration properties about the other modules running in Kepler.  They also need to be able to modify existing configuration properties that control Kepler's existing extension points without overriding the entire global configuration set, as that almost instantly guarantees modules will be incompatible with one another.   Addressing theses needs will be the focus of the Configuration system for Kepler 2.0.  However, changing the set of extension points and refactoring the GUI to provide new extension capabilities will not be part of this release.  The principal needs to be addressed by the configuration system should be:

1. Need for modules to be able to manage their own configuration properties.  This should include  a simple API for setting and reading configuration, a standardized approach for the system to load module configuration values at run time, and a way for modules to listen for property change events that might be initiated by other modules.
2. Need to consolidate configuration file serialization formats to allow easier management of configurations.
3. Need to be able to let modules set configuration properties in the *existing* Kepler system, allowing them to set configuration values that are compatible with the existing architecture and GUI (e.g., such as the names of factory classes)

Candidate foci for the next release, and/or independent module releases

    * Run manager
    * Provenance
    * Reporting
    * Tagging
    * New extensible GUI architecture