[kepler-dev] [Bug 4021] New: - KAREntry Handler

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4021

           Summary: KAREntry Handler
           Product: Kepler
           Version: 1.x dev
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: core
        AssignedTo: aschultz at nceas.ucsb.edu
        ReportedBy: leinfelder at nceas.ucsb.edu
         QAContact: kepler-dev at kepler-project.org


This is a somewhat amorphous topic for me (ben) - but I wanted to make a place
holder for it. Hopefully we can flesh it out more in the next few days. The
general gist of things (as I've talked with Debi and Aaron) is:
-KARs will contain a number of different files (serializations of object
models, jars, binary libraries, data, etc...)
-There will be a KARHandlerInterface that various subsystems (parts of
modules?) will need to implement so that they can save to and open files from
KARs.
-For example: we want to save and read ROML.xml files in KAR archives so we'd
need to write a ROMLKAREntryHandler class to mediate between the xml
serialization and the object representation. We'd also have MOMLKAREntryHandler
for the workflow model and RIOKAREntryHandler for Report instances. We might
also have more generic entry handlers for PDFs and images etc. There might also
be a JARKAREntryHandler that would deal appropriately with JARs.
-These various KAREntry items would be loaded into the object cache - always
having a unique id and also a reference to the KAR from which they originated.
-There's some glue missing from this description that will manage the
communication between KAREntryHandler instances and the cache - I hope we can
clarify that model

I'd also like to get an interface defined for the KAREntryHandler so that we
can begin implementing them for the reporting module.

Also for discussion: is this going to be in the "core" module? It is meant to
be a very core piece of Kepler, and I very much doubt we'd end up with a Kepler
distribution that did not contain it, but perhaps it should be separated for
more discrete management?