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?
#1 Updated by ben leinfelder over 13 years ago
We have the following KAREntryHandlers:
-ActorMetadata (for workflows/momls)
-ReportLayout (for ROML)
-ReportInstance for (RIO)
-WorkflowRun (for workflow run metadata)
This is sufficient for the 2a1 release for sanparks, but we need to address JAR/class entry handlers before 2.0. That can be another bug.