RE: Mutliple event components

["Torre Wenaus" <wenaus@bnl.gov>]

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

> In the second case, of "non-objectivity" files, is there something that
> distinguishes the event components in a cluster (cluster pieces)?
> An offset and
> size in the file would be reasonable.  That would be the equivalent
> of OIDs for
> non-objectivity files.  If we have this in the index, we can pass
> this to the EIs,
> thus saving the trouble to read an entire file when only some of the
>  pieces are
> needed (just as we do with object_id lists).  If so, these need to
> be generated
> and stored in the tag database (and our indexes) when these
> non-objectivity files
> are created.
>
> What do you think?
>
> Arie.
>
>