The first big question in this session is :

    --> What is the scope of interactive access to the New Micro?

The second big question is:

    --> What is the structure of the (new) Kanga event and the overall
        eventstore design?

(The two questions may not be fully answered in this session, but I hope
that by the end of the workshop we will have made good progress.)

  As Aaron will be specifically presenting the CMWG2 requirements WRT the 
"New Micro", I will leave them out here . (See the background document
links to the CMWG2 requirements and implementation documents.)

  For the second question, looking through the requirements we wrote down 
in the OCP document (BaBar Note 548) there are a number which are 
particularly relevant to this issue:

\item The system should provide a central, scalable catalog of all collections.

\item It should be possible to borrow parts of an event from a previous
      processing to avoid duplicating them (e.g. as in reskimming, 
      simulation done with 3 sequential executables or partial reprocessing)

\item Ability to write multiple collections (e.g. streams), 
      unless we completely rework our data model (not recommended).

\item Easy way of placing event components in separate files, and distributing 
      the files across file servers.

\item The system should support pointer collections.

\item The system should support collection iterators.

\item User should deal with and manage event collections, not files (if these
      are not the same).

\item File size to HPSS: average target size should be about 250~MB, and
      certainly should not be smaller than 100~MB. There is no upper limit, 
      though it probably should not go much above 10~GB. 

\item It should be possible to keep some parts of an event on disk and some on
      tape.

\item The tag structure should be flexible and easily extensible, it should not 
      put any restrictions on types of number of attributes.

This is probably not a complete list, but was a relevant set in the context
of discussing technologies which could replace the Objy eventstore in the
context of the OCP. (There are others related to data distribution and
management in that document, linked as a background document from the agenda
page, which also may have an impact on the design of a full Kanga eventstore.)
In addition, I list a number of other questions which come to mind (that
could be reexpressed as requirements after discussion):

      o How do we deal with event "metadata" like the stateID/eventID?

      o How do we deal with references between objects within the event?
        (In the same component/tree/file, in separate components/trees/files)
        (Is RooRef sufficient?)

      o The question of "borrowing" pieces of an event is probably the 
        most important one in shaping a design for the eventstore.
        Consider several use cases for this:

           o PR/SP production produces esd and aod (where is tag written?)
             [No borrowing here]

           o Skim production runs on mini, produces custom skims. These should
             have access to original mini without copying it: mini is borrowed.

           o User runs over production skims, writes out additional user data.
             Both "custom skim new micro" _and_ mini are borrowed.

           o (Further down the road) Somebody runs Moose (or BgsApp/SimApp) 
             for high background studies and turns on writing Raw/Sim so 
             they can iterate on reconstruction algorithms w/o redoing the
             expensive simulation part. Originally they write Raw/Sim/Tru
             then they run Bear over this iteratively, writing Aod/Esd, 
             "borrowing" Raw/Sim/Tru from the original collection.

      o Should Tru and Esd be written together as the "mini"? Or should they
        remain two separate components?