RE: Mutliple event components

[Arie Shoshani <arie@math.lbl.gov>]

In a meeting today with Dave Z. we decided to rely on the info

> The non-objectivity files will probably not all be the same flavor, eg. xdf and
> root, so there isn't one answer for how object location and size in the file
> can be expressed and used. But why does this help, since you have to stage in
> the whole file anyway? If GC manages staging in the file, and returns when the
> file is there, user SW can do an efficient random access read from the file of
> the event component(s), translating directly into the transient representation
> of the object(s)
>   - torre

You are right, we should not be concerned with what's in a component file.

In a meeting today with Dave Z. we agreed that it is best to assume that the user 
code will get where the event components are in a file from the event header.  So, 
in a response to a query with multiple components, we'll only return to the EI the 
list of Event_oids.  The difference is that we'll make sure now that all the 
component files for the event list are cached before we return.

Logically, for each request from the EI we get a combination of component_files 
that have in common all the pieces needed for the event_list, i.e.

[file_c(i), file_c(j), ...: {list of event_oids}],

where file_c(i) is a file for component i that contains all the event components 
for the {list of event_oids}.

Note: before we had [file: {list of event_oids}], which is a special case of the 
above multi-component extension.

Arie.