Kepler Packaging Conf. Call 2009.05.20

Kepler Packaging Conf. Call  2009.05.20

Goals of this call:
-Decide overall functionality of the packaging system
-Decide which parts of packaging subsystem to target for the 2.0 release

Relevant Bugs:
3947 - module manager
1750 - kar files
2493 - kepler repository


Previous Notes from Davis Meeting:

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 harmonize 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
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


2009.05.20 Conf. Call Notes:
------------------------------
-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
 -