2009-05-08 Meeting Requirements and Milestones Notes

Configuration subsystem

Flagged as (MUST, SHOULD, NICE) with respect to the 2.0 release milestone

Existing config systems

Ptolemy config
Java properties
Morpho config.xml
Ad-hoc uses of text files
Ptolemy user preferences
Ontology configuration files

Requirements

  -- see David's list
    1. MUST Decrease complexity
        -- fewer formats;
        -- fewer, standardized locations (one place per module)
        -- easily editable and obvious what choices are
        -- separate user-configurable properties and system/developer props
            -- may be just those that developer chooses to expose to user
    2. increased readability
    3. should support hierarchical, organized feature sets
    4. MUST: modules should be able to append to and change configuration of base system
        -- need to address security in core system (possibly out of scope)
            -- some modules may not be enabled to configure the core system
        -- modules should have their own namespaces
        -- should have resolution approach for when more than one module
overrides the same property
    5. property names should be self-describing, whole words, human
understandable
    6. configuration system should point at resources stored for module
    7. GUI configuration system should be able to be internationalized
        -- can Java support this in their properties without further implementation by us?
    8. configuration system should be able infer some defaults
    9. config system should provide GUI editing system for end users
        -- modules should be able to specify which options are end-user editable in GUI
        -- end users shouldn't have to edit text files to change configuration
   10. There should be an API for inspecting and changing options that modules can call
   11. Should be able to report all configurations and values from the build system
   12. Should be able to mark options as more or less overridable in terms of their
criticality to the module
   13. config system should allow users to change config files without obliterating
system/module defaults

Features

Deliverables

   -- Chad thinks we should consolidate on 2 formats (Ptolemy, Java Properties)

Tasks

  -- cxh to help provide documentation of ptolemy tableau/effigy system
  -- MUST evaluate whether we can consolidate to a single property system
  -- SHOULD get rid of config.xml
  -- NICE evaluate reimplementing Ptolemy, and Vergil in particular, as RCP (e.g., Eclipse)
  -- SHOULD look at i18n in Java properties to see if we can reuse it effectively
  -- MUST create ability to let modules inject new properties
  -- MUST create ability to let modules override properties from other modules
  -- SHOULD be able to add menu items from modules
  -- SHOULD be able to delete menu items
  -- MUST create tabbed/treed dialog for editing options in the GUI, modules can add their own
tabs/tree items (adapt Aaron's dialog?)
  -- MUST create API/ConfigurationManager for modules to change configuration

Milestones

  -- Release 2.0
  -- Release 2.x?
  -- End of K/C project

Core Architecture subsystem

Flagged as (MUST, SHOULD, NICE) with respect to the 2.0 release milestone

Issues to consider

1. should know what the documentation of architecture will be used for
2. should have module definition to help guide the creation of modules
3. how do we use the suite and module system to define the basic susbsytems of Kepler

Reasons to have a module/suite/{module-suite}

 1. Compartmentalize dependencies on 3rd party software (e.g., jars, native libs,
executables)
 2. Reduce redundancy via shared dependency (e.g., sharing jar files across modules)
 3. Change definition of a class in another module for experimentation
 4. Organizational: developers in sensible team packages
 5. Functional aggregation for distribution
 6. Isolate incompatible specializations
 7. Enable alternate approaches to the same feature/function to be chosen
 8. Clarifying the subsystem dependencies
 9. Isolate/distribute/upgrade code that falls at different points on the stability/change
continuum
10. Minimize size of alternate distributions
11. Highly-coupled clases should be in same module

Definition of a module

A. Module is a bunch of code and resource, can't necessarily be run, doesn't specify its
dependencies
B. Suite specifies a set of dependencies and might be able to be run

Requirements

1. Modules should support both dependencies and siblings (co-dependence)
2. Modules should not allow cyclic dependencies between modules (conflicts with 1)
3. Should have an intentionally designed set of subsystems that together they allow clear
extension and use of the subsystems
4. Architecture should provide a conceptual view of the system that maps cleanly to the
implementations
of subsystems
5. Java packages should be only in one module, and ideally include the module name in the
package name
6. Should be able to define and document extension points in modules

Features

Deliverables

1. Definition of module
2. Intentional Architecture document defining subsystems, their relationships, and APIs for
use and extension
   2a. MUST document listing of subsystems that make up Kepler (cache manager, loader, auth manager, etc.)
3. Code refactored into suites + modules that correspond to the architectural subsystems
   3a. MUST refactor only 'kernel'-related subsystems
4. MUST Refactored modules that contain 'actors'/'directors', etc.
5. Clear how-to documentation for:
   -- MUST creating a new actor
   -- MUST creating a new module
   -- MUST building and publishing modules/suites (to their own repository)
   -- NICE build your own installer?
   -- NICE using extension points from various subsystems
6. System/format for document/declare extension points that modules provide
   -- a little there because we're mostly using Factory hooks in configuration.xml

Tasks

-- check all jar files and create 'common' modules to minimize jar redundancy

Milestones

  -- Release 2.0
  -- Release 2.x?
  -- End of K/C project

Packaging subsystem

Flagged as (MUST, SHOULD, NICE) with respect to the 2.0 release milestone

Issues/Ideas

-- KAR file could be just metadata and replaces/extends MoML
  -- extension points allow new types of XML be included in the KAR file
  -- could change existing import/export to open/save functions

Requirements

Repositories...
1. Support multiple repositories? Kepler repository? Current module repository?
...More discussion needed for repositories

Packaging and loading....
2a. SHOULD should only support one packaging format for the system (merge KAR/module format)
2b. save function should save a zip file (e.g., kar) in addition to plain moml
2. light-weight loading of {data, actors} during runtime for dynamic loading without restart
3. should support modules that can be used to change system functionality
4. should be able to flag modules that require a restart
5. MUST Modules should be able to put new types of metadata in the KAR file (e.g., ROML)
6. Users should be able to create new actors and an archive that contains everything needed
to run the actor in a new kepler instance
7. When new modules load with actors need to be able to load them into the library
8. MUST If modules publish groups of actors, need to expose Actor metadata for remote searching
9. Actor search and module manager should be two alternative ways of getting the same set
of modules
   -- should be able to take a published suite and search for it in the actor search pane
10. New actors should be able to depend on code that is published in modules/suites so that
actors can be published without necessarily shipping all of the jar code
   -- when packaging an actor, only include code that is't already in another published
suite or actor kar
11. NICE Should have a GUI for selecting what goes in a package when users share a workflow
12. Using container formats for packaging should not significantly affect performance (e.g.,
 workflow load time)

Version management...
13. Should rationalize the actor versioning system (LSID) with module versioning system
14. Should have a rationale for when actor version #'s change
15. Users should be able to indicate whether changed actors represent a 'new' actor or a
revision of an 'existing' actor
...needs lots more discussion...

Licensing
16. MUST Packaging format should support well-know declaration of licensing

-Need Namespaces for code/resources within a module so that modules won't

 interfere with each other

-Common dependency format for modules/kars

  -metadata file for dependency info

  -when opening a module with a dependency file, need to check to see if

   dependencies exist and tell user if they don't

  -major version number signifies backwards compatibility

  -x.y+1 should not break functionality in x.y.  if it does, x++

  -published objects should be able to be depended on by other objects

-need versioning that doesn't depend on users' knowledge of previous versions or

 other versions of the same or similarly named modules

-deliverables for 2.0

 -dependency file format

 -system that we can support for at least 5 years

Features

Deliverables

-- change kar file format to correspond to module format

Tasks

-- review licensing and create persistent mechanism for

Milestones

  -- Release 2.0
  -- Release 2.x?
  -- End of K/C project

Data Management and Access subsystem

This category was in the high priority category but we did not reach it in time for adequate discussion.  Details still need to be determined.

Requirements

Features

Deliverables

Tasks

Milestones