[kepler-dev] Code Freeze Proposal

[Aaron Schultz]

Hi Chad, here is what I have so far on the KAR specification.

What:
----------

The Kar system will allow files to be packaged together in a jar file 
with a manifest that conforms
 to the Kar Manifest specification.
 https://kepler-project.org/developers/teams/framework/kepler-archive-kar/kar-manifest-specification
 
The Kar system will provide a standard mechanism for module specific 
serialization of objects to the Kar file
 AND to the Kepler Cache system.  In other words every KAR entry has at 
least two serialized forms:
   a serialized form in the KAR, and a serialized form in the cache.  
Currently the serialized form in the
   cache must be a Java serialized object.  The non-serialized form of a 
KAR entry must provide a mechanism
   for storing, at the very least, the LSID information for the object 
so that it's Kar Manifest information
   can be retrieved from the cache based on the LSID.
 
The Kar system will not depend on the gui.

The Kar system will give all modules in the system a chance to 
contribute entries to the KAR file on save.

The Kar system will provide a standardized way for opening the entries 
of a kar file.


How:
----------

Previously:

Module developer adds a KAREntryHandler and registers it in the system.
 From a standardized save context in the gui (i.e. an extension of 
ExportArchiveAction)
  NamedObjs were added to a SaveKAR object, the SaveKar (via KARBuilder) 
would then
  pass the LSIDs of the NamedObjs from the SaveKAR to all of the 
registered KarEntryHandler save methods
  and the EntryHandler was responsible for returning an appropriate KAR 
entry based on the LSID it received.
    This is perhaps too general because any NamedObj can be added to a 
SaveKar which makes it
    confusing for developers what they should do with it.

Proposal:

Really what we want to save in a KAR is one or more ComponentEntities 
(i.e. workflow or actor) along with any
  files that depend on that ComponentEntity in a general sense and in a 
specific save context we want
  the ability to pick and choose which dependencies get added.

So to narrow the scope of the system we say that the SaveKar ONLY 
accepts ComponentEntities
  and then those ComponentEntities (not just their LSIDs) are passed to 
the KAREntryHandlers.
  Those handlers then return an array of KAREntries that should be 
included in the KAR.
  To pick and choose from dependencies the Save context would need to 
record what should be saved
    (perhaps based on a user's selection in the gui) and then that list 
can be used by the EntryHandler
    to determine exactly which KAREntries should be returned for a given 
ComponentEntity.
 
We need a KarGenericFile class for saving generic files in KARs.  This 
will properly handle copying the
  files out of the KAR and into the cache.  This type of object does not 
have serialized forms and acts
  simply as a wrapper while in memory.

We need to address LSID issues on non-NamedObjs.  An Interface that 
includes methods like,
  getLSID and getLSIDReferralList and updateLSIDRevision is needed for 
anyone wanting to use
  non-NamedObjs in a KAR file.


Aaron

Chad Berkley wrote:
> Hi,
>
> A few of us chatted this morning about the current bug list and the 
> release.  We would like to propose a code freeze target of *January 
> 31st, 2010*.  The big bugs that we're still working on include:
>
> * KAR subsystem bugs:  May need a slight redesign or respecification. 
> Needs unit tests built.  Aaron is going to create a text document 
> outlining the use cases of the KAR system and I am going to try to 
> write unit tests to those specifications.
>
> * Documentation: figure out how to allow modules to include 
> documentation that shows up with the other kepler help docs
>
> * Module Manager: figure out the current bugs and talk further about 
> how modules are integrated into the runtime environment.
>
> * other release bugs: There are a lot of smaller bugs, some of which 
> may be ironed out in the tasks above, but nonetheless, need to be 
> addressed.  Sean, Chad and Debi will work on this until others are 
> done with their tasks.
>
> Let us know if there are other concerns to be put in this list.  Also, 
> please update any bugs assigned to you and close any that have been 
> completed.    
>
> Thanks,
> chad
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>