[kepler-dev] Code Freeze Proposal

[Chad Berkley]

Hey Aaron,

See my comments below:


Aaron Schultz wrote:
> 
> 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.

What is controlling the save (i.e. what is the trigger for saving a 
kar?)  It seems like any module could save the kar along the way, but 
I'm not sure how the kar system would give each module a chance to add 
stuff before a save.  Are you proposing a listener system for kar changes?

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

So, the componentEntity gets to choose the objects in the kar?  How 
would these objects be associated with the component entity?

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

Perhaps a system-wide lookup table for these type of objects would work. 
    Maybe we should generalize this to all objects, including component 
entities.  Then the lsid would only be embedded in the component entity 
when it is saved or somehow transfered (i.e. uploaded to a repository).

I feel like we've kind of struggled with associating object IDs in 
kepler for a while and it would be nice to come up with a good generic 
method for doing this.  It would be nice if it could be the starting 
point for allowing tighter user control over revisioning.

I'd like to see some use case type statement for this.  I think they 
would be helpful in better defining what we need to do.

Overall, I like the plan though.  It seems pretty straight-forward.

chad


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